Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

For Loop mystery

 
Anjali Pal
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Experts,

Its bugging me a lot so i am turning to the last resort i want to ask

Why is the code below is legal and produces an infinite loop.



is this because there is no condition to stop the loop?(for being infinite loop).
And why are we entering inside the loop

Regards,
Anjali
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is all specified in the JLS.
 
Anjali Pal
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot .
 
Rooks Forgenal
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why doesn't the compiler put the kibosh on that before it becomes a problem? What is the point of allowing that statement? Doesn't an empty boolean equal null and isn't null false and thereby allowing this statement to fall through? What is the difference between that and this?


Answer is utterly ridiculous!

14.14.1.2 Iteration of for statement
...
If the Expression is not present, then the only way a for statement can complete normally is by use of a break statement.
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jake benn wrote:Why doesn't the compiler put the kibosh on that before it becomes a problem?
Why would it become a problem?

jake benn wrote:What is the point of allowing that statement?
Why not when its behavior is specified.

jake benn wrote:Doesn't an empty boolean equal null and isn't null false and thereby allowing this statement to fall through?
No. Null is not false. It are 2 completely different things. This does not compile:


jake benn wrote:What is the difference between that and this?
No difference.
 
Rooks Forgenal
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It does not make it 'sound' logic to maintain its existence for no other reason than, "...its behavior is specified".
 
Campbell Ritchie
Sheriff
Pie
Posts: 50208
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is some logic in that it is a construct familiar to users of C and C++ since about 1972.
 
W. Joe Smith
Ranch Hand
Posts: 710
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Plus, if they went and all of a sudden said "Hey, you can't do that anymore" and made the next version of Java not allow it, there could be a huge number of programs that break because they use that particular code. That would be bad.
 
Rooks Forgenal
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am a programmer and I approve of modifying the behavior of languages to make them cleaner, more powerful and more secure even if it breaks pre-existing code. If it breaks code, there will be a greater need for talented and responsible programmers to fix it. The more they fix it, the better software becomes over time. Having to always find a "work around" for language bugs (JavaScript, I am talking about you) is lunacy. Losing this bit of functionality in Java could break stuff, true, but it would be easy to recover and make code easier to read, make the language more succinct and make me happy. The last part is most important.
 
W. Joe Smith
Ranch Hand
Posts: 710
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that the language should push people to write cleaner and more secure code, but I don't think it should break pre-existing code. What if there was a company that had loads of business critical processes that depended on code that, once upgraded, broke? By saying that not all pre-existing code will work with a newer version (especially with a VERY common construct such as a for loop) it would be like saying "Hey, go through all your code line by line to find out if you can actually upgrade." The man hours to do that, even in a small company, would be huge.
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with the both of you. I think that a new version of java should not break code of the previous version. However I find it acceptable if it breaks code of the version before that. There are methods in the JDK that are deprecated since version 1.1 . No class/method has ever been removed out of the JDK!
 
Campbell Ritchie
Sheriff
Pie
Posts: 50208
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with W Joe Smith that old code which works should not be "broken".
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java 5 and 6 broke code. Simple example:

Works in java 1.4 but not 5.
Therefor we could state that an upgrade is allowed to break 0.01% of the code.
 
W. Joe Smith
Ranch Hand
Posts: 710
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True, that did break code between 1.4 and 5. I don't know of any other way that the java developers could have handled putting in enums, though, even if I don't like the fact that it broke code.

To be honest I see where you are coming from, and you do have a point about writing cleaner, potentially better performing code. I just know that it would be very costly for an organization with hundred of thousands, or millions, of lines of code to go through it all to make those kinds of adjustments. By the time they finished the next version of the language would already be obsolete! I also think that rewriting the code to utilize newer methods, or to no longer use things like deprecated methods, should be done if possible. With limited time and money, however, I know that isn't usually an option.
 
Rooks Forgenal
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am aware that I have hijacked this thread. I am aware that by responding, I am making it worse. I take full responsibility for my actions and any consequences I might face in this response.

Now then, as a business owner or investor, it happens sometimes that in order for you to take steps forward, you need to take steps back. Breaking code that was reliant on bugs in a language will only serve to help the company in the long run no matter how many lines of code need to be changed. The number of lines of code will very likely be reduced in the process, causing the maintainability of the code to be more manageable. The BIGGEST cost of large programs is maintenance. I feel that the ends justify the means.

This is true especially on the internet. Security is atrocious, abysmal, and currently irreparable without massive investment in extremely talented programmers who are in VERY short supply. The cost of fixing it without correcting the languages would be orders of magnitude more costly. Because they both cost a great deal of money and time and both destabilize the infrastructure of whoever is using the software, nothing is being done about it at all. Without a paradigm shift here, we will continue to support a system of producing terrible and unstable code to the detriment of everyone. Something must be done. I feel this is the only answer no matter how painful.

Oh and P.S. something like this will increase demand for programmers. Demand increases our pay, and the quantity of jobs available. We would be the beneficiaries of this.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic