Printing the letters from A to Z using a Java stream












10














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







share|improve this question




















  • 4




    Related stackoverflow.com/a/32424763/1746118
    – nullpointer
    10 hours ago
















10














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







share|improve this question




















  • 4




    Related stackoverflow.com/a/32424763/1746118
    – nullpointer
    10 hours ago














10












10








10


3





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







share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 1 hour ago









Peter Mortensen

13.5k1983111




13.5k1983111










asked 14 hours ago









fastcodejava

23.9k19109162




23.9k19109162








  • 4




    Related stackoverflow.com/a/32424763/1746118
    – nullpointer
    10 hours ago














  • 4




    Related stackoverflow.com/a/32424763/1746118
    – nullpointer
    10 hours ago








4




4




Related stackoverflow.com/a/32424763/1746118
– nullpointer
10 hours ago




Related stackoverflow.com/a/32424763/1746118
– nullpointer
10 hours ago












2 Answers
2






active

oldest

votes


















15














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:




  1. No boxing overhead thus more efficient

  2. if you were to stop at say letter h with the use of iterate you'd have to do more brain processing than just entering h as the upper bound with rangeClosed because you'd need to find the number to truncate the infinite stream upon.

  3. Along with the boxing iterate generates an infinite stream which in this specific case has more overhead than the finite one with rangeClosed. Further, it's far easier to run IntStream.rangeClosed in 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...






share|improve this answer























  • "iterate generates an infinite stream which again has more overhead than a finite one." why's that?
    – Alexander
    6 hours 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
    4 hours ago





















12














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






share|improve this answer



















  • 1




    Good answer, would have been even better if you explain why ++i works and i + i doesn't.
    – fastcodejava
    11 hours ago






  • 1




    and much better if you could also answer Why is the Java type inference is failing part specifically :)
    – nullpointer
    11 hours ago






  • 1




    @fastcodejava I have edited my answer to try to explain.
    – GBlodgett
    10 hours ago






  • 2




    1 👏🏻 for awesome explanation @GBlodgett
    – Deadpool
    10 hours ago











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
});


}
});














draft saved

draft discarded


















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









15














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:




  1. No boxing overhead thus more efficient

  2. if you were to stop at say letter h with the use of iterate you'd have to do more brain processing than just entering h as the upper bound with rangeClosed because you'd need to find the number to truncate the infinite stream upon.

  3. Along with the boxing iterate generates an infinite stream which in this specific case has more overhead than the finite one with rangeClosed. Further, it's far easier to run IntStream.rangeClosed in 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...






share|improve this answer























  • "iterate generates an infinite stream which again has more overhead than a finite one." why's that?
    – Alexander
    6 hours 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
    4 hours ago


















15














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:




  1. No boxing overhead thus more efficient

  2. if you were to stop at say letter h with the use of iterate you'd have to do more brain processing than just entering h as the upper bound with rangeClosed because you'd need to find the number to truncate the infinite stream upon.

  3. Along with the boxing iterate generates an infinite stream which in this specific case has more overhead than the finite one with rangeClosed. Further, it's far easier to run IntStream.rangeClosed in 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...






share|improve this answer























  • "iterate generates an infinite stream which again has more overhead than a finite one." why's that?
    – Alexander
    6 hours 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
    4 hours ago
















15












15








15






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:




  1. No boxing overhead thus more efficient

  2. if you were to stop at say letter h with the use of iterate you'd have to do more brain processing than just entering h as the upper bound with rangeClosed because you'd need to find the number to truncate the infinite stream upon.

  3. Along with the boxing iterate generates an infinite stream which in this specific case has more overhead than the finite one with rangeClosed. Further, it's far easier to run IntStream.rangeClosed in 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...






share|improve this answer














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:




  1. No boxing overhead thus more efficient

  2. if you were to stop at say letter h with the use of iterate you'd have to do more brain processing than just entering h as the upper bound with rangeClosed because you'd need to find the number to truncate the infinite stream upon.

  3. Along with the boxing iterate generates an infinite stream which in this specific case has more overhead than the finite one with rangeClosed. Further, it's far easier to run IntStream.rangeClosed in 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...







share|improve this answer














share|improve this answer



share|improve this answer








edited 4 hours ago

























answered 14 hours ago









Aomine

39.2k73669




39.2k73669












  • "iterate generates an infinite stream which again has more overhead than a finite one." why's that?
    – Alexander
    6 hours 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
    4 hours ago




















  • "iterate generates an infinite stream which again has more overhead than a finite one." why's that?
    – Alexander
    6 hours 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
    4 hours ago


















"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
6 hours ago




"iterate generates an infinite stream which again has more overhead than a finite one." why's that?
– Alexander
6 hours 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
4 hours 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
4 hours ago















12














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






share|improve this answer



















  • 1




    Good answer, would have been even better if you explain why ++i works and i + i doesn't.
    – fastcodejava
    11 hours ago






  • 1




    and much better if you could also answer Why is the Java type inference is failing part specifically :)
    – nullpointer
    11 hours ago






  • 1




    @fastcodejava I have edited my answer to try to explain.
    – GBlodgett
    10 hours ago






  • 2




    1 👏🏻 for awesome explanation @GBlodgett
    – Deadpool
    10 hours ago
















12














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






share|improve this answer



















  • 1




    Good answer, would have been even better if you explain why ++i works and i + i doesn't.
    – fastcodejava
    11 hours ago






  • 1




    and much better if you could also answer Why is the Java type inference is failing part specifically :)
    – nullpointer
    11 hours ago






  • 1




    @fastcodejava I have edited my answer to try to explain.
    – GBlodgett
    10 hours ago






  • 2




    1 👏🏻 for awesome explanation @GBlodgett
    – Deadpool
    10 hours ago














12












12








12






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






share|improve this answer














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







share|improve this answer














share|improve this answer



share|improve this answer








edited 10 hours ago

























answered 14 hours ago









GBlodgett

9,15641633




9,15641633








  • 1




    Good answer, would have been even better if you explain why ++i works and i + i doesn't.
    – fastcodejava
    11 hours ago






  • 1




    and much better if you could also answer Why is the Java type inference is failing part specifically :)
    – nullpointer
    11 hours ago






  • 1




    @fastcodejava I have edited my answer to try to explain.
    – GBlodgett
    10 hours ago






  • 2




    1 👏🏻 for awesome explanation @GBlodgett
    – Deadpool
    10 hours ago














  • 1




    Good answer, would have been even better if you explain why ++i works and i + i doesn't.
    – fastcodejava
    11 hours ago






  • 1




    and much better if you could also answer Why is the Java type inference is failing part specifically :)
    – nullpointer
    11 hours ago






  • 1




    @fastcodejava I have edited my answer to try to explain.
    – GBlodgett
    10 hours ago






  • 2




    1 👏🏻 for awesome explanation @GBlodgett
    – Deadpool
    10 hours ago








1




1




Good answer, would have been even better if you explain why ++i works and i + i doesn't.
– fastcodejava
11 hours ago




Good answer, would have been even better if you explain why ++i works and i + i doesn't.
– fastcodejava
11 hours ago




1




1




and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
11 hours ago




and much better if you could also answer Why is the Java type inference is failing part specifically :)
– nullpointer
11 hours ago




1




1




@fastcodejava I have edited my answer to try to explain.
– GBlodgett
10 hours ago




@fastcodejava I have edited my answer to try to explain.
– GBlodgett
10 hours ago




2




2




1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
10 hours ago




1 👏🏻 for awesome explanation @GBlodgett
– Deadpool
10 hours ago


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







-

Popular posts from this blog

Bundesstraße 106

Image
Dieser Artikel beschreibt die Bundesstraße 106 in Deutschland. Zur gleichnamigen Straße in Österreich siehe Mölltal Straße. Vorlage:Infobox hochrangige Straße/Wartung/DE-B Bundesstraße 106 in Deutschland Karte Basisdaten Betreiber: Deutschland  Bundesrepublik Deutschland Straßenbeginn: Wismar ( 53° 54′  N , 11° 24′  O 53.900536 11.396875 ) Straßenende: Schwerin ( 53° 36′  N , 11° 24′  O 53.592785 11.404892 ) Gesamtlänge: 40,7 km Bundesland: Mecklenburg-Vorpommern Ausbauzustand: zweistreifig [1] Bundesstraße 106 in Schwerin (Umgehungsstraße) Straßenverlauf Land Mecklenburg-Vorpommern Landkreis Nordwestmecklenburg Ortsumgehung Wismar Wallensteingraben über   Dorf Mecklenburg Wallensteingraben Groß Stieten Bad Kleinen OT Niendorf Bahnstrecke Lübeck–Bad Kleinen Zickhusen Lübstorf Klein Trebbow OT Kirch Stück
Read more

Verónica Boquete

Image
Verónica Boquete im Trikot der Nationalmannschaft (2013) Personalia Name Verónica Boquete Giadans Geburtstag 9. April 1987 Geburtsort Santiago de Compostela, Spanien Größe 159 cm Position Mittelfeld / Sturm Juniorinnen Jahre Station 2001–2005 Xuventú Aguiño Frauen Jahre Station Spiele (Tore) 1 2005–2008 Prainsa Zaragoza 83 (40) 2008–2010 Espanyol Barcelona 53 (30) 2010 Buffalo Flash 9 0 (9) 2010 Chicago Red Stars 3 0 (1) 2010–2011 Espanyol Barcelona 26 (41) 2011 Philadelphia Independence 13 0 (5) 2011 Energija Woronesch 5 0 (1) 2012–2014 Tyresö FF 39 (14) 2014 Portland Thorns FC 15 0 (4) 2014–2015 1. FFC Frankfurt 23 0 (7) 2015–2016 FC Bayern München 9 0 (0) 2016–2018 Paris Saint-Germain 31 0 (8) 2018 Peking BG Phoenix 2019– Utah Royals FC 0 0 (0) Nationalmannschaft Jahre Auswahl
Read more

Ida-Boy-Ed-Garten

Image
Die Lage des Ida-Boy-Ed-Gartens, rot markiert Der Ida-Boy-Ed-Garten Der Ida-Boy-Ed-Garten, Blick von der Wakenitzmauer durch das Tor in der Stadtmauer Der Ida-Boy-Ed-Garten ist eine Straße der Lübecker Altstadt. Inhaltsverzeichnis 1 Lage 2 Geschichte 3 Literatur 4 Weblinks Lage | Der etwa 90 Meter lange Ida-Boy-Ed-Garten befindet sich an der nördlichen Spitze der Altstadtinsel, vor dem Burgtor. Die in einem Bogen durch eine Grünanlage hangaufwärts führende Straße verbindet die Wakenitzmauer mit der Burgtorbrücke. Geschichte | Der heutige Ida-Boy-Ed-Garten wurde ursprünglich als Verlängerung der Wakenitzmauer angelegt. 1903 wurde in den erhaltenen Teil der mittelalterlichen Stadtmauer, an dem die Wakenitzmauer bei der Einmündung der Kaiserstraße begann, ein Tor mit einem großen Bogen für die Durchführung der Straße und zwei kleineren seitlichen Öffnungen für Fußgänger gebrochen, um für die neu errichteten Wohnhäuser in diesem Bereich
Read more