UnThreaded | Threaded | Whole Thread (31) | Ignore Thread Prev Thread | Next Thread
Author: stockmover Big red star, 1000 posts Old School Fool CAPS All Star Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: of 189603  
Subject: Yet another Java flaw Date: 9/30/2012 6:21 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
Seems like there is no end to Java security issues ....

<snip>

by Jon Brodkin - Sept 25 2012, 3:20pm USMST
Researchers have discovered a Java flaw that would let hackers bypass critical security measures in all recent versions of the software. The flaw was announced today by Security Explorations, the same team that recently found a security hole in Java SE 7 letting attackers take complete control of PCs. But this latest exploit affects Java SE 5, 6, and 7—the last eight years worth of Java software.

(cont)

http://arstechnica.com/security/2012/09/yet-another-java-fla...

Rich
Arizona
Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182024 of 189603
Subject: Re: Yet another Java flaw Date: 9/30/2012 6:39 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 2
There may be to end to them, but there is a way to avoid them completely.

Don't install Java. And if you already have it installed, then remove it.

I've become so dissatisfied with Java that if some app or website requires it, I find an alternative app or website.

SJK
(Java free for almost a year!)

Print the post Back To Top
Author: Donna405 Big gold star, 5000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182028 of 189603
Subject: Re: Yet another Java flaw Date: 10/1/2012 12:41 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
I also removed Java about a year ago, with no problems. Like SJK, if I do encounter any problems, sobeit.

Donna

Print the post Back To Top
Author: branmin Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182031 of 189603
Subject: Re: Yet another Java flaw Date: 10/1/2012 10:35 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
What actually is Java used for? And if a particular site says you need to install in order to access the site..how do you get around this?...I have had Java for years, can't say i have noticed any problems, but anything to reduce security issues....

Print the post Back To Top
Author: tketola Three stars, 500 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182032 of 189603
Subject: Re: Yet another Java flaw Date: 10/1/2012 10:52 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
Hey branmin,,,,

What actually is Java used for?

Read here, should give a pretty good picture:

http://www.java.com/en/download/faq/whatis_java.xml

TK...

Print the post Back To Top
Author: mmrmnhrm Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182033 of 189603
Subject: Re: Yet another Java flaw Date: 10/1/2012 11:21 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
What actually is Java used for?

When you want to be able to write the code once, and run it on a variety of systems without the hassle of recompiling for any number of $OS and $ARCH variables. There isn't a whole lot of this given how (despite Mac fanboi's protestations otherwise) $OS is generally Win6.1 or higher, and $ARCH is nearly always i586 or compatible. However, there are folks out there who cater to diverse environments, where $OS could be Windows, OSX, Linux, or BSD, and $ARCH could be practically anything built in the last ten years. In those cases, Java put together with free standards like OpenGL can be a godsend.

Print the post Back To Top
Author: ptheland Big gold star, 5000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182036 of 189603
Subject: Re: Yet another Java flaw Date: 10/2/2012 12:48 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 3
Let me see if I can translate mmrmmmhrnnmmhr's response. (Sorry, I can never remember the right number of letters in his/her username.) :-)

Java is a programming language. What makes it handy for web site designers is that the user has to install a program on their computer that handles all of the details of making the program run on any specific kind of computer. It's a program that runs other programs.

So all the web guy has to do is write the program to do what they want it to do. They don't have to worry about all of the differences between Windows and Macs and UNIX users. That's handled by the Java piece the user has to install.

You might be able to see the problem here. If you let a program run on your computer, you're giving that program access to your computer. And with Java, you're giving access to some random web site designer to do an awful lot of things on your computer.

One of the bad guys favorite things to do is to create errors. (That would be something like trying to divide by zero.) Programmers generally are pretty good at handling errors, but they're not perfect. So the bad guys poke around a lot until they find some kind of error that isn't handled correctly. That can make the computer do unexpected things. Those baddies find out what that unexpected thing is and then take advantage of it to get more access to your computer than you think you gave them.

Often, they'll take advantage of that additional access to install another program on your computer without your permission. That stuff is malware. It generally does bad things. At best, it just makes your computer run slower. At worst, it steals various pieces of information and sends them on to the baddies, who figure out a way to convert that information into money.

And that's my translation of the problem with Java. It's not that Java is a badly written program. On the contrary, it's fairly well-written. The problem is that by its very nature it creates security holes. And those holes are difficult to impossible to close. The only real way to close the security holes is to get rid of Java completely. That means you might not be able to do some things on some web sites. But that's the price to pay for eliminating this particular security threat.

--Peter

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: mmrmnhrm Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182038 of 189603
Subject: Re: Yet another Java flaw Date: 10/2/2012 3:31 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 8
Peter, you start off ok, but then kinda lose it, as the blame lies just as much in the programmer as it does with Java itself.

Java is a programming language. What makes it handy for web site designers is that the user has to install a program on their computer that handles all of the details of making the program run on any specific kind of computer. It's a program that runs other programs.

So all the web guy has to do is write the program to do what they want it to do. They don't have to worry about all of the differences between Windows and Macs and UNIX users. That's handled by the Java piece the user has to install.

So far, so good. Let me take you back to the early childhood of personal computing... 1985. The lingua franca of the world, and an ancestor of Java (in spirit if not flesh), is BASIC. Functionally, it is identical. It is, in your words, "a program that runs other programs." It didn't matter whether you wrote (or copied out of a magazine) the code to an IBM PC-XT, a Commodore 64, an Apple IIc (or one of them newfangled Macintosh thingies), an Amiga, or an Atari XL, as long as the computer had a BASIC interpreter, it would run the program. If by some miracle you could find a computer that could read disks other than its own native format, you could even copy the programs from one to the other, make no changes, and have them work! Just like your modern-day web programmer.

You might be able to see the problem here. If you let a program run on your computer, you're giving that program access to your computer.
This is where you begin to wander off the trail. There is no problem here. The very act of running a program gives it access to your computer. It doesn't matter whether the program is written in Java, C, C++, C#, FORTRAN, COBOL, LISP, VB, .NET, ASM, or any other number of languages, both arcane and common. Is C# somehow more secure than C++? Or COBOL more secure than Java? No. In fact, some languages have even less ability to protect the user from malware than Java, as they lack the security certificate mechanisms (which are currently giving me all sorts of grief as I try to get an older program running again).

And with Java, you're giving access to some random web site designer to do an awful lot of things on your computer.
And this is different from .NET, PHP, ASP, VB, Flash, and HTML5 how, exactly?

One of the bad guys favorite things to do is to create errors. (That would be something like trying to divide by zero.) Programmers generally are pretty good at handling errors, but they're not perfect. So the bad guys poke around a lot until they find some kind of error that isn't handled correctly. That can make the computer do unexpected things. Those baddies find out what that unexpected thing is and then take advantage of it to get more access to your computer than you think you gave them.

Often, they'll take advantage of that additional access to install another program on your computer without your permission. That stuff is malware. It generally does bad things. At best, it just makes your computer run slower. At worst, it steals various pieces of information and sends them on to the baddies, who figure out a way to convert that information into money.

And here we're getting to where I think you're going wrong. Programmers *SUCK* at detecting and handling errors, to the point that college exercises are designed specifically to make students think about what happens if unexpected input is received. If the assignment is to return the sine of an angle, and you store it as type integer, what happens when the user feeds you a float? How about if you store a float, but the user provides a double? Or worse, a string!! Bad People(tm) take advantage not of the language directly, but of programmer inexperience, incompetence, or sheer laziness. Sanitize your input, and it doesn't matter what is fed in, garbage in = try again loser!

Often, they'll take advantage of that additional access to install another program on your computer without your permission. That stuff is malware. It generally does bad things. At best, it just makes your computer run slower. At worst, it steals various pieces of information and sends them on to the baddies, who figure out a way to convert that information into money.
Yes, but again, how is this any different from exploiting holes in Internet Explorer, Firefox, Chrome, Safari, and Opera, or any of their plug-ins (I'm looking at you, Flash and Adobe Reader)?

And that's my translation of the problem with Java. It's not that Java is a badly written program. On the contrary, it's fairly well-written. The problem is that by its very nature it creates security holes. And those holes are difficult to impossible to close. The only real way to close the security holes is to get rid of Java completely. That means you might not be able to do some things on some web sites. But that's the price to pay for eliminating this particular security threat.
No, just because it exists doesn't create security holes. Or rather, it enables only the security holes the programmers or compiliers create by not testing their software, or assuming someone/something else will handle protecting users. Get rid of Java completely? Then what will programmers use when cross-platform compatibility is needed? Sorry, but I don't think anybody wants to figure out how to extend BASIC to handle high-res 3D graphics and optimal path routing. I suppose it sort of goes back to a discussion I had with my father back in the late 90's, when I told him Microsoft was pants-down stupid to be turning things on left and right when they weren't needed (and causing all sorts of hacking problems as a result). Dad's view was "someone might need it!" My view was "Then don't turn it on until it's actually asked for!"

All that said, whether or not Java belongs on the web *IS* a legitimate question. Personally, I don't think it does. Java is for applications, not for games on Facebook. Everything a web designer might want to accomplish can usually be handled through the browser itself, maybe with the help of JavaScript (which is usually what people are thinking of when they talk about Java exploits, a separate issue of its own) and/or Flash (which has security issues of its own). Pick the right tool for the job. If you don't need the broadsword, then by all means leave it home and just carry a dagger instead!

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: ptheland Big gold star, 5000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182039 of 189603
Subject: Re: Yet another Java flaw Date: 10/2/2012 4:28 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
Thanks for the additional insights. I'm an admitted amateur at this stuff, although I'm trying to learn more.

And with Java, you're giving access to some random web site designer to do an awful lot of things on your computer.
And this is different from .NET, PHP, ASP, VB, Flash, and HTML5 how, exactly?


I suppose it's not much different at all. But it is different from, say, installing Office or a game or some utility. With those, you know you're installing a program and have some idea of who wrote it and, presumably, you trust them. With these web-based programs, you have no idea what's going on. (Although doesn't ASP run on the server side and not on the client computer?) You're turning over your computer to some unknown programmer. And you may not even realize that you're doing so.

Programmers *SUCK* at detecting and handling errors,

Really? I've only taken a couple of programming classes (mainly in that venerable BASIC, and a great many moons ago), and handling errors was one of the few things I took away from the class. Maybe I was lucky in the instruction I received.

Still, if they're not doing a good job of handling error situations, that creates the opportunities the black hats are exploiting.

All that said, whether or not Java belongs on the web *IS* a legitimate question. Personally, I don't think it does. ... Pick the right tool for the job. If you don't need the broadsword, then by all means leave it home and just carry a dagger instead!

Perhaps that gets to the action item for us mere mortals. If you refuse to use Java, you may have to use other ways of accomplishing something on the web. If that means you are calling customer service instead of handling it on a company's web site, you're making a statement to the company that their web site is not doing what you need it to do. Call my glasses rose-colored if you wish, but if enough people do that often enough, the company may change their web site to work without Java.

--Peter

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: mmrmnhrm Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182040 of 189603
Subject: Re: Yet another Java flaw Date: 10/2/2012 8:59 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
I suppose it's not much different at all. But it is different from, say, installing Office or a game or some utility. With those, you know you're installing a program and have some idea of who wrote it and, presumably, you trust them. With these web-based programs, you have no idea what's going on. (Although doesn't ASP run on the server side and not on the client computer?) You're turning over your computer to some unknown programmer. And you may not even realize that you're doing so.
The only difference, in this context, is that a program like Office requires you to consciously go to a store (whether it's brick-and-mortar or an online e-store doesn't really matter) and install it, while a Java program is often automatically executed by the browser without bothering to ask the user first (because, y'know, if they didn't want the program, they wouldn't have come to the website, amiright?). This isn't really the user's fault, but rather the browser's for just running any executable that it happens to encounter along the way. A user can cause just as much damage to their system by opening a malicious Word document as they can by running a Java program. The only difference is that with Word, there's the added step of "Please download and mail this file to begin your warranty claim" (or whatever reason-du-jour provided by the phishing email is).

Really? I've only taken a couple of programming classes (mainly in that venerable BASIC, and a great many moons ago), and handling errors was one of the few things I took away from the class. Maybe I was lucky in the instruction I received.

Still, if they're not doing a good job of handling error situations, that creates the opportunities the black hats are exploiting.

Yup. Though in many instances, it's also a question of scope. By any measure, BASIC was pretty limited in what it allowed one to do with a system: load/save files, make the speaker emit strange noises, draw graphics. But by being limited, the worst you could do to your system was overwrite a system file (oops! boot from floppy and restore). Divide by zero? Program would either crash back to the interpreter command line, or return something silly. Divide zero by zero (c'mon, I know you want to)? Same. Some might say it's the programmer's job to handle all errors (like the academic exercise of throwing junk at a sine function I mentioned earlier), but that just isn't realistically going to happen. Once an error escape's the programmer's scope, it's up to the runtime environment to prevent things from getting out of hand. This is where the *NIX world shines, with very granular limits on both what programs are allowed to do, and also on what users are allowed to do. Not only does the program need permission to do something, but the user running that program also needs permission. If either check fails, the operation also fails. Unfortunately, Windows hasn't gotten to that level yet (which is why, despite the falling number of successful attacks on Windows itself, the problem is getting worse instead of better because such restrictions aren't enforced on client software like Adobe Reader, Word/Excel macros, and, yes, Java).

Perhaps that gets to the action item for us mere mortals. If you refuse to use Java, you may have to use other ways of accomplishing something on the web. If that means you are calling customer service instead of handling it on a company's web site, you're making a statement to the company that their web site is not doing what you need it to do. Call my glasses rose-colored if you wish, but if enough people do that often enough, the company may change their web site to work without Java.
You're going back to blaming the messenger and not the message. There's no reason why *JAVA* is bad. The problem is that browsers just go ahead and execute it without bothering to ask "Hey, I just saw this and, well, webmasters who actually know what they're doing don't typically do this. Do you really want me to run it?" Again, I think you're conflating Java with JavaScript. JS is a whole 'nuther terd, and I really wish it would die in a fire. As it stands, though, it seems that Oracle is doing it's darndest to, well, I'm not exactly sure what. It's like they don't really know what to do with Sun's last great invention, and apart from providing fixes as problems crop up, I haven't seen any huge leaps forward in functionality or speed lately.

(I can't believe the Fool thinks 'terd' with a 'u' is profanity)

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: branmin Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182041 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 12:06 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
Ask a silly question perhaps, but with respect to all, this has now gone way over my head:-))))

Print the post Back To Top
Author: dsbrady Big funky green star, 20000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182042 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 11:39 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
And this is different from .NET, PHP, ASP, VB, Flash, and HTML5 how, exactly?

It's actually significantly different from PHP, ASP, .NET, and VB (as far as using a web browser goes). Those never run on the client machine and only end up rendering HTML. While Java can run on the back end as those do, in that manner it doesn't present a risk to the users themselves. It's when it's running on the client itself that is the problem (which is also an issue with Flash and, to a lesser extent, HTML 5).

dsbrady

Print the post Back To Top
Author: mmrmnhrm Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182043 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 1:18 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
It's actually significantly different from PHP, ASP, .NET, and VB (as far as using a web browser goes). Those never run on the client machine and only end up rendering HTML. While Java can run on the back end as those do, in that manner it doesn't present a risk to the users themselves. It's when it's running on the client itself that is the problem (which is also an issue with Flash and, to a lesser extent, HTML 5).

To a programmer, you're 100% correct. To an end user, though, there's no meaningful difference. Sort of how Peter viewed a store-bought application such as Office as being more "trustworthy" than Zynga's latest Farmville rip-off... the only thing server-side dynamic code generation does is add the extra step of forcing the bad guys to create a malformed request via PHP, CGI, or whatever server-side language is being used, uploading it to the server, then exploiting the results to hijack the server itself before sending malicious payloads to end users. The end user doesn't know that the code came from a hacked server rather than an infected app, only that their computer is once again acting really weird, and the kid down the street told them to just buy a new one and start over.

Print the post Back To Top
Author: ptheland Big gold star, 5000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182044 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 1:32 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
the only thing server-side dynamic code generation does is add the extra step of forcing the bad guys to create a malformed request via PHP, CGI, or whatever server-side language is being used, uploading it to the server, then exploiting the results to hijack the server itself before sending malicious payloads to end users.

I guess that's a part I don't understand. I can see how running some program on your own computer (whether it's Office or a game or Java) can create a threat to your computer. But how does running a program on a server cause a threat to you when browsing the web?

--Peter

Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182045 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 2:04 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
The lingua franca of the world, and an ancestor of Java (in spirit if not flesh), is BASIC. Functionally, it is identical.

Wrong on both counts.

A Java VM is a virtual machine, and it's ancestor in spirit is the Pascal p-machine and p-code. Programmers write apps in Java (or Pascal), compile that code to Java bytecode (or P-code), and execute that code on a Java VM (or P-machine).

In essence, the language designers invented a CPU which only existed in the virtual machine, but not in the real world.

Both Java and Pascal are compiled languages, and functionally are very different from the interpreted BASIC of years ago. The big problem with BASIC was that virtually every implementation varied slightly. Even Microsoft BASIC wasn't a standard — apps written in Microsoft BASIC on PC-DOS wouldn't run in Microsoft BASIC on the Altair, nor on an Apple II.

I programmed in BASIC on a DEC PDP 11-/70, the IBM PC, the Apple II, Commodore 64 and the Atari 800. I can't think of a single BASIC app from one of those machines that could run unmodified on on of the others.

Print the post Back To Top
Author: mmrmnhrm Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182047 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 4:19 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
I guess that's a part I don't understand. I can see how running some program on your own computer (whether it's Office or a game or Java) can create a threat to your computer. But how does running a program on a server cause a threat to you when browsing the web?

Initially, it doesn't cause a threat. Let's say the server is running what's called a LAMP stack (short for Linux-Apache-MySQL-PHP), and the admins haven't been very diligent with security patches. On day zero, everything is all fine and dandy, the world is pure and clean, and everything is great. Then on day one, Bad People come and exploit a month old vulnerability in PHP, where it passes invalid arguments to MySQL that cause a buffer overflow and remote code execution bug in Apache, the end result of which is gaining root (superuser) rights to the Linux host. When you're "root" you can do *anything* and the machine will follow you right off the volcano's edge and into the bubbling pool of magma below if you so order it.

So these Bad People decide that rather than just throw a bunch of graffiti on the websites (which, while great for grabbing attention, is counter-productive to their goal of creating a botnet BECAUSE it gets attention), they write a tiny little snippet of JavaScript which embeds itself into the body of every HTML file served, and does nothing more than say "Powered by LAMP." Because JS is such an integral part of the web these days, and since every browser has support for it built-in, even the site admins don't think anything is amiss... it's just there, silently advertising to the Bad People that whatever backdoor they installed is still there. Now a month or two goes by, and the bad guys move to phase two: Taking advantage of their mark's laziness and complacency to begin installing virii/trojans/whatnot on their visitor's machines. What had been a server-side vulnerability just became the end-user's nightmare.

SJK: Yes, incompatibilities existed, and I'm sure you're very proud of being an old graybeard, but I'm not going to get into a forest-for-the-trees argument with you. Nor am I going to get into arguments about interpreters versus virtual machines versus sandboxes versus your need to swoop in here and puff yourself up. Go troll RMS, he likes that sort of thing.

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: tketola Three stars, 500 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182048 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 4:32 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
Hey Steven,,, you said:

Wrong on both counts.

A Java VM is a virtual machine, and it's ancestor in spirit is the Pascal p-machine and p-code. Programmers write apps in Java (or Pascal), compile that code to Java bytecode (or P-code), and execute that code on a Java VM (or P-machine).
Java uses a two step compilation process. Java source code is compiled down to "bytecode" by the Java compiler. The bytecode is executed by Java Virtual Machine (JVM). The current version of Sun HotSpot JVM uses a technique called Just-in-time (JIT) compilation to compile the bytecode to the native instructions understood by the CPU on the fly at run time.


Yes you are!!!

Regardless of how the Execution takes place, by Compilation or Interpretation, depends on the particular Machine and Implementation, the Tools Supported, etc. It can be and is done both ways, by Compilation or Interpretation, read below!!!

So, in my mind anyway, any initial Source-Code-Compilation that does NOT directly result in Executable/Loadable-Machine-Code, is still being Interpreted, one way or another.

Using JIT, JVM, Bytecode, etc., in any combination is still Interpretation, on the Fly or NOT.!!!

Just my opinion...

TK...
____________________________________________________

http://stackoverflow.com/questions/1326071/is-java-a-compile...

Java uses a two step compilation process. Java source code is compiled down to "bytecode" by the Java compiler. The bytecode is executed by Java Virtual Machine (JVM). The current version of Sun HotSpot JVM uses a technique called Just-in-time (JIT) compilation to compile the bytecode to the native instructions understood by the CPU on the fly at run time.

Some implementations of JVM might interpret the bytecode instead of JIT compiling it to machine code and running it directly. While this is still considered an "interpreter." It's significantly different from interpreters that read and execute the high level source code (i.e. in this case, Java source code is not interpreted directly, the bytecode, output of Java compiler, is.)

To summarize, depending on the execution environment, bytecode can be:

compiled ahead of time and executed as native code (similar to C++)
compiled just-in-time and executed
interpreted
directly executed by a supported processor (bytecode is the native instruction set of some CPUs)



And...

The terms "interpreted language" or "compiled language" don't make sense, because any programming language can be interpreted and/or compiled.

As for the existing implementations of Java, most involve a compilation step to bytecode, so they involve compilation. The runtime also can load bytecode dynamically, so some form of a bytecode interpreter is always needed. That interpreter may or may not in turn use compilation to native code internally.

These days partial just-in-time compilation is used for many languages which were once considered "interpreted", for example Javascript.


____________________________________________________

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: ptheland Big gold star, 5000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182049 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 5:08 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
Now a month or two goes by, and the bad guys move to phase two: Taking advantage of their mark's laziness and complacency to begin installing virii/trojans/whatnot on their visitor's machines. What had been a server-side vulnerability just became the end-user's nightmare.

Thanks.

Then as a web surfer, it's not much different than visiting a deliberately malicious web site. In one case, the Bad Guys really are the web masters. In the other case, lazy web masters have effectively lost control of their web site to the Bad Guys. In either case, to cause me problems the Bad Guys have to take advantage of some weakness in my web browser. So I'm depending on some combination of my web browser, an anti-malware program, and my wits to defend me against the Bad Guys.

That would be a bit different from Java (where this all started). To defend against attacks coming through Java, I still can use an anti-malware program and my wits, but my web browser no longer is any help nor is it the source of the vulnerability. But I can completely eliminate the threat by simply refusing to install Java and accepting the loss of functionality Java provided.

--Peter

Print the post Back To Top
Author: mmrmnhrm Big red star, 1000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182050 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 8:14 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
Then as a web surfer, it's not much different than visiting a deliberately malicious web site. In one case, the Bad Guys really are the web masters. In the other case, lazy web masters have effectively lost control of their web site to the Bad Guys. In either case, to cause me problems the Bad Guys have to take advantage of some weakness in my web browser. So I'm depending on some combination of my web browser, an anti-malware program, and my wits to defend me against the Bad Guys.
Exactly :) The trouble is that browsers (or more often, their plug-ins) are security disasters.

That would be a bit different from Java (where this all started). To defend against attacks coming through Java, I still can use an anti-malware program and my wits, but my web browser no longer is any help nor is it the source of the vulnerability. But I can completely eliminate the threat by simply refusing to install Java and accepting the loss of functionality Java provided.
The best defense against Java-based attacks is, as you advocate, to simply not install it in the first place. For the vast majority of people, this is exactly what should be done. When I try to think of something that absolutely requires client-side Java through the browser, I come up empty. Interactive weather radar or real estate searches, games... it can all be done via server-side calls (JS+JSON+AJAX being the most common for the former, I believe, while Flash is more popular for the latter). I can't see why online banking would need any sort of client-side scripting... server-side generation of static HTML is all that's required, yet those pages are riddled with JavaScript. Video has a whole bunch of choices, with Flash being most common, though HTML5 will probably become a lot more common as browsers begin supporting it.

Java has its place, but like any tool used inappropriately, Bad Things(tm) usually follow when that happens.

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182052 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 11:19 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
And if a particular site says you need to install in order to access the site..how do you get around this?

I find another site offering a comparable service, and use that instead.

Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182053 of 189603
Subject: Re: Yet another Java flaw Date: 10/3/2012 11:40 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
Hey Steven,,, you said:

No, I didn't. It seems you concatenated part of my posting with part of someone else's posting.

Getting back to the compiled vs intepreted thing: There is no such thing as a BASIC VM. Java bytecode and Pascal P-code are machine code instructions. (Think of them as machine language for a CPU that exists only in software.) If you write a program in Pascal, and compile it to P-code, your compiled code will run on any p-machine on top of any architecture/OS.

But there isn't a BASIC machine code instruction set. There isn't even source code compatibility among the various BASIC interpreters & compilers. So BASIC source code can only run in the interpreter for which it was written. It will only compile in the compiler for whic it is written. And compiled BASIC can only run on the architecture/OS for which it is compiled.

(Interestingly, a company called Sage (or maybe SAGE) sold a computer using a bespoke CPU that actually used p-code as its instruction set, and it can compiled Pascal amazingly fast.)

Print the post Back To Top
Author: JeanDavid Big gold star, 5000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182054 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 7:02 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
And if a particular site says you need to install in order to access the site..how do you get around this?

I find another site offering a comparable service, and use that instead.


So I should find another broker for my IRA, Roth-IRA, Margin, and UGMA accounts so as to have one with a similar application for displaying my stocks and their current prices, and so on? They have an application (Java) that displays the stocks, tickers, low, high, etc., as well as graphs of prices over user-specified intervals, and so on, that update about once a second, give news, enable trades, all in one neat app. Very amusing, though I do not really need it as I do not day-trade. I actually need that about 2-month intervals.

Print the post Back To Top
Author: JeanDavid Big gold star, 5000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182055 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 7:07 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
Actually, the whole issue of whether something is compiled, interpreted, emulated, etc., is pretty funny. Some IBM/360 computers had a very different hardware instruction set from that presented to the programmers. The machine was microprogrammed present the System/360 architecture to the programmers. On some models, you could use a different microprogram and the box would appear to be an IBM 7094.

At another level, some microprocessor chips are microprogrammed to present a different instruction set and register structure. I believe even the current Intel *86 chips are not much like the architecture that is presented to the programmers, though they cannot change the microprogram.

Print the post Back To Top
Author: tketola Three stars, 500 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182059 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 11:33 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
Hey Steven,,, you said:

No, I didn't. It seems you concatenated part of my posting with part of someone else's posting.

Getting back to the compiled vs intepreted thing: There is no such thing as a BASIC VM. Java bytecode and Pascal P-code are machine code instructions. (Think of them as machine language for a CPU that exists only in software.) If you write a program in Pascal, and compile it to P-code, your compiled code will run on any p-machine on top of any architecture/OS.


The entire thread was about the problems in today's implementations of Java, and its flaws and weaknesses, as to how and why it can be Hacked and Exploited.

Then you bring in your convoluted comparison statements about, Pascal, Basic, DEC PDP 11-/70, IBM PC, Apple II, Commodore 64 and the Atari 800, that is ancient history, and have nothing to do with the subject at hand.

The only argument that I had with your Convoluted Statements, was about, what is Compiler or Assembler generated Machine Readable/Executable code vs Interpretive Code generation, and I didn't mix up anything, I quoted you statement verbatim from Post # 182058.

The fact is that, regardless of how Java Compilation or JVM/JIT is generated to Bytecode or any other intermediate code, and then subsequently executed on any machine, it's still being Interpreted at Run-Time, unless, it was Pre-Compiled again, on the specific Target Machine.

The exception to this is, that on some Machines, if so Customized, the Bytecode generated can be directly Executable as Machine Code, skipping the Bytecode to Machine Code Interpretive Code-Generation step, and even that is being done by some Interpretive Microcode, in some cases.

Also, as JeanDavid mentioned:

Actually, the whole issue of whether something is compiled, interpreted, emulated, etc., is pretty funny. Some IBM/360 computers had a very different hardware instruction set from that presented to the programmers. The machine was microprogrammed present the System/360 architecture to the programmers. On some models, you could use a different microprogram and the box would appear to be an IBM 7094.

Yes, even some Machine-Code Instructions, are being interpreted, in the Machine's Microcode, mainly for Machine-Instruction/Op-Codes that involve complex operations, such as Decimal Arithmetic, Floating-Point Arithmetic, complex Move/Compare Instructions, etc.

BTW JeanDavid, I once wrote the Decimal(String) Multiply and Decimal (String) Divide Microcode routines. Also, as a Team-Member, I wrote 2 Passes for an Assembler, and part of a ANSI/COBOL Compiler. Yes, that was long time ago!!! Incidentally, the actual Development was done on an IBM/360/Assembler, the target Machine/Hardware was a Memorex Multi/Processor-CPU, still in development, at the time when we wrote the software. Conceptually, it was sort of like, what came first, the Chicken or the Egg,,,,,, LOL...

Think about it,,, you write an Assembler and a Compiler, using a IBM/360 Assembler, that then generates the Target Machines Executable Code, that is then Loaded into the Target Machine, and used to Assemble the Target Machine's Native Assembly Source Code.

Not an exactly an easy concept, to wrap you Brain around.!!!

TK...

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182061 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 1:11 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
So I should find another broker for my IRA, Roth-IRA, Margin, and UGMA accounts so as to have one with a similar application for displaying my stocks and their current prices, and so on?

Why not? But first I'd contact that broker and ask if they're working on a version that doesn't require Java. Many web sites that formerly used Java have since switched to HTML5 solutions.

One of the drivers behind this is the fact that Java doesn't run on iPads and a nontrivial number of people browse the web using iPads. Furthermore, the demographics of iPad users makes them highly desirable to stock brokerages.

Do they have an iPad app? If so, that may be a hint that an HTML5 version is in the works.

Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182062 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 1:41 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
I didn't mix up anything, I quoted you statement verbatim from Post # 182058.

Quite a trick considering that:
• I didn't write post 182058. See for yourself: http://boards.fool.com/most-likely-you-need-to-have-an-addit...
• Post 182058 belongs to another thread, and
• The post you claim contains a "statement verbatim from Post # 182058" carries a timestamp indicate it was written almost 17 hours before 182058 was written.

Allow me to suggest that you've made some kind of an error.

Of course, if the mistake is mine, I'll gladly post an apology.

Print the post Back To Top
Author: tketola Three stars, 500 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182064 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 2:36 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
OK, my mistake,

I copied the wrong Post Number, the correct one is 182045, here:

http://boards.fool.com/the-lingua-franca-of-the-world-and-an...

And, you knew it anyway!!!

TK...

Print the post Back To Top
Author: stevenjklein Big funky green star, 20000 posts Feste Award Nominee! Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182065 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 3:06 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
But you still didn't quote me accurately. On re-reading the thread, it looks like you quoted parted of my message, and then added additional text that didn't come from any other message in this thread.

Between the two double lines is a copy & paste of what you wrote in message 182048, with the original formatting intact: http://boards.fool.com/hey-steven-you-said-wrong-on-both-cou...

========================================
Hey Steven,,, you said:

Wrong on both counts.

A Java VM is a virtual machine, and it's ancestor in spirit is the Pascal p-machine and p-code. Programmers write apps in Java (or Pascal), compile that code to Java bytecode (or P-code), and execute that code on a Java VM (or P-machine).
Java uses a two step compilation process. Java source code is compiled down to "bytecode" by the Java compiler. The bytecode is executed by Java Virtual Machine (JVM). The current version of Sun HotSpot JVM uses a technique called Just-in-time (JIT) compilation to compile the bytecode to the native instructions understood by the CPU on the fly at run time.


Yes you are!!!
========================================

The first part of that is indeed mine, but I did NOT write the part that starts "Java uses…"

I don't know if you're quoting another website, another message on this website, or something else entirely, but you're definitely NOT quoting me verbatim (as you later claimed).

I'd also like to respond to your message 182059, in which you wrote:
Then you bring in your convoluted comparison statements about, Pascal, Basic…

Actually, I didn't start down that path. My message was posted as a response to mmrmnhrm's message 182038, in which he said BASIC was the spiritual ancestor of Java. My point (with which I think you agree) is that the comparison is a poor one, since compiled Java code can be distributed to any platform that implements the Java VM, but that's not true of BASIC for which there is no VM. It is true of Pascal, and I'm hardly the first person to see the similarities between Java/bytecode and Pascal/p-code.

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: tketola Three stars, 500 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182066 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 3:28 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
OK Steve,,,

Yes, that part was part of the Web-Page-Link quoted below, and should have not been Bolded, as part of your Quote.

Well whatever, I will just drop this thread now, pretty useless conversation anyway,,, the end...

TK...

Print the post Back To Top
Author: JeanDavid Big gold star, 5000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182069 of 189603
Subject: Re: Yet another Java flaw Date: 10/4/2012 7:56 PM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 0
My favorite brain wrap arounder was the following.

I had a CCC DDP-224 computer. It had a FORTRAN compiler.
I wrote the OS for it. There was no memory management hardware, but there were interrupts and independent data channels. The interrupts were in very low memory, as was usual at the time.

I revised the assembler and FORTRAN compiler to produce relocatable code by default, and revised the loader to load above 0ctal 100 to avoid the transfer vectors.

When I compiled a particular program, involving 13 nested DO loops (a FFT program), the whole system crashed. I could see that the transfer vectors for the interrupts had been overwritten by the compiler at compilation time. But where in that 12,000-card program was the error?

I wrote an interpreter in assembly language for a computer exactly like the 224, but with memory management. The interpreter took DDP-224 hardware instructions and simulated them in the interpreter. So if I loaded the compiler into the simulated machine (running on the real machine), it would trap any attempt to write on the transfer vectors. That all worked and I debugged the compiler in a few minutes.

But when I went to test that simulator-interpreter-emulator, I ran the regular hardware test programs, and they all worked OK except the memory test program that failed miserably.

What happened was that the interpreter kept the address counter in RAM (no place else to put it; the real address counter was running the interpreter). And the memory test program wrote all over the unused memory, and read it back to see if it compared. And it did not. In particular, the memory address where the program counter was changed.

It took a while to understand that.

When you get a failure with a thing like that, it is tough to have the correct mental model of what is going on. Is the real computer having a problem? Or is the simulated computer having a problem? Or is the simulator program having a problem?

Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Print the post Back To Top
Author: Philipo Big funky green star, 20000 posts Old School Fool Add to my Favorite Fools Ignore this person (you won't see their posts anymore) Number: 182070 of 189603
Subject: Re: Yet another Java flaw Date: 10/5/2012 7:20 AM
Post New | Post Reply | Reply Later | Create Poll . Report this Post | Recommend it!
Recommendations: 1
"Why not?"

How about the obvious - it's a PITA.
B

Print the post Back To Top
UnThreaded | Threaded | Whole Thread (31) | Ignore Thread Prev Thread | Next Thread
Advertisement