aspose file tools *
The moose likes Beginning Java and the fly likes For Loop mystery Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "For Loop mystery" Watch "For Loop mystery" New topic
Author

For Loop mystery

Anjali Pal
Greenhorn

Joined: Oct 03, 2009
Posts: 16
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

Joined: Oct 25, 2008
Posts: 2700

It is all specified in the JLS.


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Anjali Pal
Greenhorn

Joined: Oct 03, 2009
Posts: 16
Thanks a lot .
Rooks Forgenal
Ranch Hand

Joined: Jun 05, 2009
Posts: 82
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

Joined: Oct 25, 2008
Posts: 2700

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

Joined: Jun 05, 2009
Posts: 82
It does not make it 'sound' logic to maintain its existence for no other reason than, "...its behavior is specified".
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40079
    
  28
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

Joined: Feb 10, 2009
Posts: 710
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.


SCJA
When I die, I want people to look at me and say "Yeah, he might have been crazy, but that was one zarkin frood that knew where his towel was."
Rooks Forgenal
Ranch Hand

Joined: Jun 05, 2009
Posts: 82
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

Joined: Feb 10, 2009
Posts: 710
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

Joined: Oct 25, 2008
Posts: 2700

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

Joined: Oct 13, 2005
Posts: 40079
    
  28
I agree with W Joe Smith that old code which works should not be "broken".
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

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

Joined: Feb 10, 2009
Posts: 710
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

Joined: Jun 05, 2009
Posts: 82
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.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: For Loop mystery