Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #32455 > unrolled thread

questions re Javascript

Started byrdelaney2001@gmail.com
First post2015-09-01 15:26 -0700
Last post2015-09-24 12:04 -0400
Articles 20 on this page of 105 — 10 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  questions re Javascript rdelaney2001@gmail.com - 2015-09-01 15:26 -0700
    Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-01 23:26 +0000
      Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-02 10:00 +0100
        Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-02 05:32 -0700
          Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-03 20:17 -0400
            Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-04 05:33 -0700
              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:42 -0400
    Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-01 20:00 -0400
    Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-05 20:40 +0100
      Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-23 16:10 -0700
        Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 10:40 +0100
          Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 11:21 +0000
            Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 20:10 +0100
              Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:18 -0700
                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:40 -0400
                  Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 01:15 +0000
                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:25 -0400
                  Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:59 -0400
                      Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
                  Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:02 -0700
                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-02 16:24 -0400
                      Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 23:02 -0400
                        Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 13:30 +0100
                          Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-04 21:31 -0700
                            Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-05 07:48 +0100
                          Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 20:53 -0400
                        Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:46 -0400
                          Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:00 -0400
                            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:19 -0400
                              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:26 -0400
                Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
              Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-24 16:58 -0400
                Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 21:45 +0000
                Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 18:27 -0400
                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:53 -0400
                  Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:03 -0400
                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:34 -0400
                      Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:46 -0400
                        Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:56 -0400
                          Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 10:15 -0400
                            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 11:44 -0400
                              Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 14:09 -0400
                                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 15:15 -0400
                                  Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:45 -0400
                                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:48 -0400
                                      Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 03:29 +0000
                                        Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 00:02 -0400
                                          Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 11:33 +0000
                                            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 10:44 -0400
                              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:42 -0400
                                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:51 -0400
                          Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:38 -0400
                            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:59 -0400
                              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:47 -0400
                                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:48 -0400
                              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:53 -0400
                                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:52 -0400
                                  Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:03 -0400
                                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:25 -0400
                                      Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:41 -0400
                                        Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:11 -0400
                                          Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:19 -0400
                                            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:27 -0400
                  Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 22:30 -0400
                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:42 -0400
                      Re: Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, and compiling. Englewood Cliffs, N.J: Prentice-Hall. Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:26 -0400
                    Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:07 -0400
                      Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:55 -0400
                        Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:46 -0400
                    Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-25 05:20 -0700
                      Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:54 -0400
                        Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:05 -0400
                          Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:36 -0400
                            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:57 -0400
                              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:10 -0400
                                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:27 -0400
                      Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:19 -0400
                Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:35 -0400
          Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:10 -0700
            Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:55 -0400
              Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 00:48 +0000
                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 20:55 -0400
                  Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 11:17 +0000
                    Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 12:30 +0100
                      Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:00 +0000
                        Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:03 -0400
                          Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:14 -0400
                          Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 19:59 +0000
                            Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 17:13 -0400
                              Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 22:15 +0000
                      Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:07 -0700
                        Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 16:48 +0100
                    Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:02 -0400
                      Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:32 +0000
                Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:45 +0100
                  Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:13 -0400
              Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 21:58 -0400
                Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:34 -0400
                Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:35 -0400
                  Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:51 -0400
                    Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:00 -0400
                      Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:17 -0400
    Re: questions re Javascript Tim Slattery <tim@risingdove.com> - 2015-09-24 12:04 -0400

Page 1 of 6  [1] 2 3 4 5 6  Next page →


#32455 — questions re Javascript

Fromrdelaney2001@gmail.com
Date2015-09-01 15:26 -0700
Subjectquestions re Javascript
Message-ID<cef9fe09-3475-485e-bd05-28796e775945@googlegroups.com>
I'm trying to get a handle in what Javascript is, isn't, 
what it does....

Is it a language, or a set of library routines?  If 
the latter, how are they accessed?  

Is it used, or useful, for anything besides hovering
the cursor over an image on a Web page?
 
What is its relation to Java, as a plug-in?  Are they 
independent?  Does Javascript execute/reside 'inside' 
Java, so to speak?

What are the limitations of the language, in terms of 
hardware, memory access, security, etc.?
 

Thx,
 
--
Rich


 

[toc] | [next] | [standalone]


#32456

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2015-09-01 23:26 +0000
Message-ID<ms5c7l$816$1@dont-email.me>
In reply to#32455
On Tue, 01 Sep 2015 15:26:38 -0700, rdelaney2001 wrote:

> I'm trying to get a handle in what Javascript is, isn't,
> what it does....
> 
> Is it a language, or a set of library routines?  If the latter, how are
> they accessed?
>
Its a language, originally developed by Netscape to allow input 
validation, etc, to be carried out locally on the HTML browser.
 
> Is it used, or useful, for anything besides hovering the cursor over an
> image on a Web page?
>  
Yes. Very many web pages are infested with it.

> What is its relation to Java, as a plug-in?  Are they independent?  Does
> Javascript execute/reside 'inside' Java, so to speak?
>
No relation whatsoever. 

Java is a strongly typed, compiled OO language that was designed to be 
executed in a portable virtual machine. It can be run in a sandbox on a 
client system.

Javascript is an untyped, interpreted scripting language. The interpreter 
is usually a component of the web browser. Javascript is often executed 
without being sandboxed.

> What are the limitations of the language, in terms of hardware, memory
> access, security, etc.?
>  
Pass. I looked at it many years ago, couldn't find a decently written 
book about it (I was looking for the equivalent of K&R's "The C 
Programming Language"), decided I didn't like the language anyway and 
haven't looked at it since. There are others on c.l.j.p. who may be able 
to describe its limitations, but you should really be asking about 
javascript on a javascript newsgroup. This a Java one.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]


#32462

FromEternal Hope <laughingspam99@gmail.com>
Date2015-09-02 10:00 +0100
Message-ID<ms6doe$53k$1@dont-email.me>
In reply to#32456
On 02/09/2015 00:26, Martin Gregorie wrote:
> On Tue, 01 Sep 2015 15:26:38 -0700, rdelaney2001 wrote:
>
>> I'm trying to get a handle in what Javascript is, isn't,
>> what it does....
>>
>> Is it a language, or a set of library routines?  If the latter, how are
>> they accessed?
>>
> Its a language, originally developed by Netscape to allow input
> validation, etc, to be carried out locally on the HTML browser.
>
>> Is it used, or useful, for anything besides hovering the cursor over an
>> image on a Web page?
>>
> Yes. Very many web pages are infested with it.

Ha ha, not a fan then.

Actually I'm starting to find Javascript invaluable.
AJAX is possibly the single most important technology stack when
it comes to making web sites more like desktop applications. My 
commercal sites make heavy use of AJAX and I get universal approval from 
my customers when it comes to useability.

<snip>


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]


#32464

Frome.d.programmer@gmail.com
Date2015-09-02 05:32 -0700
Message-ID<fd2b2ad7-67ef-4358-861f-5215e9c094a8@googlegroups.com>
In reply to#32462
On Wednesday, September 2, 2015 at 5:00:58 AM UTC-4, Eternal Hope wrote:
> Ha ha, not a fan then.
> 
> Actually I'm starting to find Javascript invaluable.
> AJAX is possibly the single most important technology stack when
> it comes to making web sites more like desktop applications. My 
> commercal sites make heavy use of AJAX and I get universal approval from 
> my customers when it comes to useability.

Most up to date websites include Javascript these days.  Modern browsers like Chrome and Edge are killing support for older web technologies.
Facebook for one loves AJAX because it can run independently, so they can load your newsfeed and a sidebar simultaneously.
If you want to write web code it helps to stick with anything supported by the w3c, and they do have documentation on Javascript.

http://www.w3.org/standards/webdesign/script

Save the following text to a .html file and you can view it in a browser to see a sample of Javascript interactivity.

<html><body><div style='width:100%;height:140px;'><div style="background-color:#D94A38;width:170px;height:80px;margin:20px;padding-top:20px;color:#ffffff;font-weight:bold;font-size:18px;float:left;text-align:center;" onmouseover="this.innerHTML='Thank You'" onmouseout="this.innerHTML='Mouse Over Me'">Mouse Over Me</div><div style="background-color:#D94A38;width:170px;height:80px;margin:20px;padding-top:20px;color:#ffffff;font-weight:bold;font-size:18px;float:left;text-align:center;" onclick="clickMeEvent(this)">Click Me</div><script type="application/javascript">function clickMeEvent(obj){if (obj.innerHTML=="Goodbye"){obj.style.display="none";}else if (obj.innerHTML=="Thank You"){obj.innerHTML="Goodbye";}else if (obj.innerHTML=="Click Me<br>Click Me Again<br>And Again"){obj.innerHTML="Thank You";}else if (obj.innerHTML=="Click Me<br>Click Me Again"){obj.innerHTML=obj.innerHTML+"<br>And Again";}else{obj.innerHTML=obj.innerHTML+"<br>Click Me Again";}}</script></div></body></html>

[toc] | [prev] | [next] | [standalone]


#32508

FromArne Vajhøj <arne@vajhoej.dk>
Date2015-09-03 20:17 -0400
Message-ID<msanuu$2hm$4@speranza.aioe.org>
In reply to#32464
On 9/2/2015 8:32 AM, e.d.programmer@gmail.com wrote:
> On Wednesday, September 2, 2015 at 5:00:58 AM UTC-4, Eternal Hope wrote:
>> Actually I'm starting to find Javascript invaluable.
>> AJAX is possibly the single most important technology stack when
>> it comes to making web sites more like desktop applications. My
>> commercal sites make heavy use of AJAX and I get universal approval from
>> my customers when it comes to useability.
>
> Most up to date websites include Javascript these days.  Modern browsers like Chrome and Edge are killing support for older web technologies.

Really?

What in server side generated HTML 4.01 or 2.0 does not work any more?

Arne

[toc] | [prev] | [next] | [standalone]


#32519

Frome.d.programmer@gmail.com
Date2015-09-04 05:33 -0700
Message-ID<471d88a0-da29-4697-bac2-5833dd767713@googlegroups.com>
In reply to#32508
On Thursday, September 3, 2015 at 8:17:44 PM UTC-4, Arne Vajhøj wrote:
> > Most up to date websites include Javascript these days.  Modern browsers like Chrome and Edge are killing support for older web technologies.
> 
> Really?
> 
> What in server side generated HTML 4.01 or 2.0 does not work any more?
> 
> Arne

Who said anything about HTML?  I said browsers are killing "older web technologies".
https://java.com/en/download/faq/chrome.xml
https://dev.modern.ie/platform/faq/activex

[toc] | [prev] | [next] | [standalone]


#32825

FromArne Vajhøj <arne@vajhoej.dk>
Date2015-10-05 22:42 -0400
Message-ID<5613350c$0$303$14726298@news.sunsite.dk>
In reply to#32519
On 9/4/2015 8:33 AM, e.d.programmer@gmail.com wrote:
> On Thursday, September 3, 2015 at 8:17:44 PM UTC-4, Arne Vajhøj wrote:
>>> Most up to date websites include Javascript these days.  Modern browsers like Chrome and Edge are killing support for older web technologies.
>>
>> Really?
>>
>> What in server side generated HTML 4.01 or 2.0 does not work any more?
>
> Who said anything about HTML?  I said browsers are killing "older web technologies".
> https://java.com/en/download/faq/chrome.xml
> https://dev.modern.ie/platform/faq/activex

Ah.

Guess we have a slightly different understanding of what "older"
web technologies are.

:-)

Arne

[toc] | [prev] | [next] | [standalone]


#32457

FromArne Vajhøj <arne@vajhoej.dk>
Date2015-09-01 20:00 -0400
Message-ID<ms5e7i$su0$1@speranza.aioe.org>
In reply to#32455
On 9/1/2015 6:26 PM, rdelaney2001@gmail.com wrote:
> I'm trying to get a handle in what Javascript is, isn't,
> what it does....
>
> Is it a language, or a set of library routines?  If
> the latter, how are they accessed?

It is a language.

It is standardized under the rarely used name ECMAScript.

> Is it used, or useful, for anything besides hovering
> the cursor over an image on a Web page?

Yes.

You can build very complex web applications running
client side in the browser and only have web services
server side.

Like GMail etc..

You can make server side web applications using node.js.

> What is its relation to Java, as a plug-in?  Are they
> independent?  Does Javascript execute/reside 'inside'
> Java, so to speak?

It is a completely different language than Java.

NetScape just made a business deal with SUN to use
the Java prefix.

Also some of the basic language methods in JavaScript
are similar to Java.

But do let that fool you - Java and JavaScript are
very different languages,

There are several integration points between
Java and JavaScript though:
* JavaScript can call Java applets in the browser
* Java applets can call JavaScript in the browser
* some JavaScript engines are implemented in Java
* Java actually comes with one of those embedded
   out of the box

> What are the limitations of the language, in terms of
> hardware, memory access, security, etc.?

That is more than can be answered in a usenet post.

Arne

[toc] | [prev] | [next] | [standalone]


#32541

FromEternal Hope <laughingspam99@gmail.com>
Date2015-09-05 20:40 +0100
Message-ID<msfgbb$945$1@dont-email.me>
In reply to#32455
On 01/09/2015 23:26, rdelaney2001@gmail.com wrote:
> I'm trying to get a handle in what Javascript is, isn't,
> what it does....
>
> Is it a language, or a set of library routines?  If
> the latter, how are they accessed?
>
> Is it used, or useful, for anything besides hovering
> the cursor over an image on a Web page?
>
> What is its relation to Java, as a plug-in?  Are they
> independent?  Does Javascript execute/reside 'inside'
> Java, so to speak?
>
> What are the limitations of the language, in terms of
> hardware, memory access, security, etc.?

Are you still reading this OP?
Are you any clearer in your mind?

Read what Martin Gregorie wrote upthread, it's
nicely succinct although for completeness he possibly could have 
mentioned that technically Java is also an interpreted language although 
optimizations like Just In Time compilers tend to blur the distinction 
somewhat.

Ignore the other, (hijacked subject) thread, it's just mental 
masturbation by people who obviously have nothing better to do. :-)

-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]


#32644

FromLew <lewbloch@gmail.com>
Date2015-09-23 16:10 -0700
Message-ID<83722e36-4afe-4077-b936-229450613698@googlegroups.com>
In reply to#32541
On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope wrote:
> ... technically Java is also an interpreted language although 
> optimizations like Just In Time compilers tend to blur the distinction 
> somewhat.

"Technically" Java is a compiled language.

-- 
Lew

[toc] | [prev] | [next] | [standalone]


#32645

FromEternal Hope <laughingspam99@gmail.com>
Date2015-09-24 10:40 +0100
Message-ID<mu0g9p$ljt$1@dont-email.me>
In reply to#32644
On 24/09/2015 00:10, Lew wrote:
> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope wrote:
>> ... technically Java is also an interpreted language although
>> optimizations like Just In Time compilers tend to blur the distinction
>> somewhat.
>
> "Technically" Java is a compiled language.

Ambiguous.


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]


#32646

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2015-09-24 11:21 +0000
Message-ID<mu0mbs$ak9$1@dont-email.me>
In reply to#32645
On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:

> On 24/09/2015 00:10, Lew wrote:
>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
>> wrote:
>>> ... technically Java is also an interpreted language although
>>> optimizations like Just In Time compilers tend to blur the distinction
>>> somewhat.
>>
>> "Technically" Java is a compiled language.
> 
> Ambiguous.

FWIW, my take on it is that a language that can be run without a separate 
compilation step is interpreted (bash scripts, Perl, awk, BASIC) while 
'compiled' languages always involve a separate compilation step, before 
they can be run.

To me, the fact that Java has to be run in a JVM is not relevant to this 
argument: nobody ever claimed that UCSD Pascal was interpreted despite 
the face that its compiler output P-code that needed a runtime translator 
to execute it. If you count Java and P-coded compilation systems as 
'interpreted languages' then you must also include, say, 6800 assembler 
as an 'interpreted language' if its being run on an Intel box with the 
air of a 6800 emulator.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]


#32652

FromEternal Hope <laughingspam99@gmail.com>
Date2015-09-24 20:10 +0100
Message-ID<mu1hnf$sq8$1@dont-email.me>
In reply to#32646
On 24/09/2015 12:21, Martin Gregorie wrote:
> On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:
>
>> On 24/09/2015 00:10, Lew wrote:
>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
>>> wrote:
>>>> ... technically Java is also an interpreted language although
>>>> optimizations like Just In Time compilers tend to blur the distinction
>>>> somewhat.
>>>
>>> "Technically" Java is a compiled language.
>>
>> Ambiguous.
>
> FWIW, my take on it is that a language that can be run without a separate
> compilation step is interpreted (bash scripts, Perl, awk, BASIC) while
> 'compiled' languages always involve a separate compilation step, before
> they can be run.

Well when I went to school (jeez, was it *that* long ago) a compiled 
language was one where the compiler took source code as input and 
produced native machine code that was directly executable on the 
underlying hardware as output.

Anything else wasn't and isn't

A Java compiler takes source code as input and produces output that 
requires interpretation by a platform specific machine that 'looks up' 
the relevant platform specific instruction and it is that that is 
executed on the underlying hardware.

Call it 'beans and bacon' if you like, I call that interpretation.

Of course, there are any number of 'interpretations' [:-)] that can be 
put on words, words are abstractions of reality used to build more 
complex abstractions of reality and as such can be used to mean whatever 
you want if you try hard enough.

It doesn't really matter though does it? I mean it's not going to make 
any difference to the future of mankind is it? I'm more concerned with 
preventing this solid state Asus thingy from being forcibly updated to 
the Pay As You Spy As You Go platform called windows 10.

Thank god for the gcc compiler and the Linux kernel :-)
That is still the compiler of choice isn't it?

> To me, the fact that Java has to be run in a JVM is not relevant to this
> argument: nobody ever claimed that UCSD Pascal was interpreted despite
> the face that its compiler output P-code that needed a runtime translator
> to execute it. If you count Java and P-coded compilation systems as
> 'interpreted languages' then you must also include, say, 6800 assembler
> as an 'interpreted language' if its being run on an Intel box with the
> air of a 6800 emulator.
>
>


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]


#32654

FromLew <lewbloch@gmail.com>
Date2015-09-24 13:18 -0700
Message-ID<3552aa8f-51c1-46f1-9029-b28208c76ee8@googlegroups.com>
In reply to#32652
On Thursday, September 24, 2015 at 12:10:51 PM UTC-7, Eternal Hope wrote:
> On 24/09/2015 12:21, Martin Gregorie wrote:
> > On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:
> >
> >> On 24/09/2015 00:10, Lew wrote:
> >>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
> >>> wrote:
> >>>> ... technically Java is also an interpreted language although
> >>>> optimizations like Just In Time compilers tend to blur the distinction
> >>>> somewhat.
> >>>
> >>> "Technically" Java is a compiled language.
> >>
> >> Ambiguous.
> >
> > FWIW, my take on it is that a language that can be run without a separate
> > compilation step is interpreted (bash scripts, Perl, awk, BASIC) while
> > 'compiled' languages always involve a separate compilation step, before
> > they can be run.
> 
> Well when I went to school (jeez, was it *that* long ago) a compiled 
> language was one where the compiler took source code as input and 
> produced native machine code that was directly executable on the 
> underlying hardware as output.

You misunderstood your classes.

> Anything else wasn't and isn't

Not consistent with the rest of the world, your interpretation.

> A Java compiler takes source code as input and produces output that 

A Java what? What was that word? Wait, was it "compiler"? A Java "compiler"? So what does a Java "compiler" do? Could it be that it *compiles* the Java language source code? As a result of which the Java code is what? Compiled? And yet Java is not a compiled language?

WTF?

> requires interpretation by a platform specific machine that 'looks up' 
> the relevant platform specific instruction and it is that that is 
> executed on the underlying hardware.

So bytecode is interpreted. Bytecode is not Java, in case you hadn't noticed.

Compilers don't compile into machine code. They compile into assembly code of some kind. The assembly for Java is called "bytecode". 

Notice that the C compiler produces ".o" files, which are not directly runnable.

> Call it 'beans and bacon' if you like, I call that interpretation.

WTF? again

You are right that *bytecode* is interpreted. What did bytecode get emitted by again? What was that tool called? A "compiler"? Which does what to Java code again?

> Of course, there are any number of 'interpretations' [:-)] that can be 
> put on words, words are abstractions of reality used to build more 
> complex abstractions of reality and as such can be used to mean whatever 
> you want if you try hard enough.

There are right "interpretations" of technical terms, and there are wrong ones. Yours is of the latter type.

Again, not to put too fine a point on it, the *bytecode* that gets interpreted (which is NOT Java) is produced by what tool?

> It doesn't really matter though does it? I mean it's not going to make 
> any difference to the future of mankind is it? I'm more concerned with 
> preventing this solid state Asus thingy from being forcibly updated to 
> the Pay As You Spy As You Go platform called windows 10.

Oh, so if you finally ever do admit you were wrong about this, you can say, "It doesn't really matter, anyway", and protect your ego. Got it.

> 
> Thank god for the gcc compiler and the Linux kernel :-)
> That is still the compiler of choice isn't it?
> 
> > To me, the fact that Java has to be run in a JVM is not relevant to this

Java is not run in a JVM.

Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C.

> > argument: nobody ever claimed that UCSD Pascal was interpreted despite
> > the face that its compiler output P-code that needed a runtime translator
> > to execute it. If you count Java and P-coded compilation systems as
> > 'interpreted languages' then you must also include, say, 6800 assembler
> > as an 'interpreted language' if its being run on an Intel box with the
> > air of a 6800 emulator.

WTF? 

I point out again that Java code is not interpreted. It is process through a tool called a "compiler", program name "javac", which "compiles" the Java source code. That makes Java "compiled".

Java is not interpreted. Show me where it is. Not on the JVM; the JVM doesn't run Java code.

-- 
Lew

[toc] | [prev] | [next] | [standalone]


#32659

FromJerry Stuckle <jstucklex@attglobal.net>
Date2015-09-24 19:40 -0400
Message-ID<mu21gr$pln$1@dont-email.me>
In reply to#32654
On 9/24/2015 4:18 PM, Lew wrote:
> On Thursday, September 24, 2015 at 12:10:51 PM UTC-7, Eternal Hope wrote:
>> On 24/09/2015 12:21, Martin Gregorie wrote:
>>> On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:
>>>
>>>> On 24/09/2015 00:10, Lew wrote:
>>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
>>>>> wrote:
>>>>>> ... technically Java is also an interpreted language although
>>>>>> optimizations like Just In Time compilers tend to blur the distinction
>>>>>> somewhat.
>>>>>
>>>>> "Technically" Java is a compiled language.
>>>>
>>>> Ambiguous.
>>>
>>> FWIW, my take on it is that a language that can be run without a separate
>>> compilation step is interpreted (bash scripts, Perl, awk, BASIC) while
>>> 'compiled' languages always involve a separate compilation step, before
>>> they can be run.
>>
>> Well when I went to school (jeez, was it *that* long ago) a compiled 
>> language was one where the compiler took source code as input and 
>> produced native machine code that was directly executable on the 
>> underlying hardware as output.
> 
> You misunderstood your classes.
>

No, he didn't.  It was that way in my classes in the 1960's and 1970's,
also.

>> Anything else wasn't and isn't
> 
> Not consistent with the rest of the world, your interpretation.
> 

Completely consistent.

>> A Java compiler takes source code as input and produces output that 
> 
> A Java what? What was that word? Wait, was it "compiler"? A Java "compiler"? So what does a Java "compiler" do? Could it be that it *compiles* the Java language source code? As a result of which the Java code is what? Compiled? And yet Java is not a compiled language?
> 
> WTF?
> 

The Java compiler changes source code into byte code.  It does NOT
create machine-readable code.

A compiler simply changes one version of code to another; in this case
it converts source code into byte code.  But that does NOT mean it is
the same as compiled code - which (until Java pundits have tried to
change the definition) has always referred to code directly executable
by the machine.  It does NOT refer to "assembler code" - which actually
is just a text representative of machine code.

>> requires interpretation by a platform specific machine that 'looks up' 
>> the relevant platform specific instruction and it is that that is 
>> executed on the underlying hardware.
> 
> So bytecode is interpreted. Bytecode is not Java, in case you hadn't noticed.
> 

Yes, in case you haven't noticed - Java Bytecode IS Java - as opposed to
bytecode in other languages.

> Compilers don't compile into machine code. They compile into assembly code of some kind. The assembly for Java is called "bytecode". 
> 

See above.  But you've already shown you understand neither assembler
nor machine code - much less the difference between the two.

> Notice that the C compiler produces ".o" files, which are not directly runnable.
> 

No, they have to be linked to the libraries, first.  But that does not
change the fact the .o code is machine executable code; it's just
missing necessary libraries.  But the code itself is executable machine
code.

>> Call it 'beans and bacon' if you like, I call that interpretation.
> 
> WTF? again
> 

He is correct.

> You are right that *bytecode* is interpreted. What did bytecode get emitted by again? What was that tool called? A "compiler"? Which does what to Java code again?
> 

Bytecode is generated by the Java Compiler.  But that does not mean the
result is "compiled code" as is generally recognized by experts in the
computer community.  Only those with limited Java experience consider it
that.

>> Of course, there are any number of 'interpretations' [:-)] that can be 
>> put on words, words are abstractions of reality used to build more 
>> complex abstractions of reality and as such can be used to mean whatever 
>> you want if you try hard enough.
> 
> There are right "interpretations" of technical terms, and there are wrong ones. Yours is of the latter type.
>

His is of the former type.

> Again, not to put too fine a point on it, the *bytecode* that gets interpreted (which is NOT Java) is produced by what tool?
> 

And what is the bytecode if it is not compiled Java?  Can it be
interpreted by a Basic interpreter?

>> It doesn't really matter though does it? I mean it's not going to make 
>> any difference to the future of mankind is it? I'm more concerned with 
>> preventing this solid state Asus thingy from being forcibly updated to 
>> the Pay As You Spy As You Go platform called windows 10.
> 
> Oh, so if you finally ever do admit you were wrong about this, you can say, "It doesn't really matter, anyway", and protect your ego. Got it.
> 

No, he only admits that it's not going to change the future of mankind.
 He admits nothing about being wrong - because he isn't.  But you don't
understand that.

>>
>> Thank god for the gcc compiler and the Linux kernel :-)
>> That is still the compiler of choice isn't it?
>>
>>> To me, the fact that Java has to be run in a JVM is not relevant to this
> 
> Java is not run in a JVM.
> 

Then what is it run in?  A BASIC interpreter?

> Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C.
> 

No, Java is not compiled into machine code.  Although there are
third-party tools which will convert Java into machine code. the Java
compiler creates byte code.

If Java were compiled into machine code, it could not run on multiple
platforms under multiple OS's.  The fact it can do that proves it is not
machine code - because every platform and every OS has a different
machine code interface.

>>> argument: nobody ever claimed that UCSD Pascal was interpreted despite
>>> the face that its compiler output P-code that needed a runtime translator
>>> to execute it. If you count Java and P-coded compilation systems as
>>> 'interpreted languages' then you must also include, say, 6800 assembler
>>> as an 'interpreted language' if its being run on an Intel box with the
>>> air of a 6800 emulator.
> 
> WTF? 
> 
> I point out again that Java code is not interpreted. It is process through a tool called a "compiler", program name "javac", which "compiles" the Java source code. That makes Java "compiled".
> 

And once again you are wrong.

> Java is not interpreted. Show me where it is. Not on the JVM; the JVM doesn't run Java code.
> 

The fact it requires a JVM to run, and the same compiled code runs on
multiple platforms with no change is proof.

But there are always noobs who think they know more than the experts.
unfortunately, Java seems to have more than its fair share.  I guess
that's because java noobs don't need to understand the difference.

Those of us who have worked for years on multiple platforms in multiple
languages understand better.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#32664

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2015-09-25 01:15 +0000
Message-ID<mu2782$cn$2@dont-email.me>
In reply to#32659
On Thu, 24 Sep 2015 19:40:02 -0400, Jerry Stuckle wrote:

> No, Java is not compiled into machine code.  Although there are
> third-party tools which will convert Java into machine code. the Java
> compiler creates byte code.
>
Errr, Java can be compiled into machine code: such compilers exist. GCJ 
could generate either bytecode or machine code for a quite large range of 
architectures. I'm only saying 'could' because the website has no news 
items later than 2009.
  
> If Java were compiled into machine code, it could not run on multiple
> platforms under multiple OS's.  The fact it can do that proves it is not
> machine code - because every platform and every OS has a different
> machine code interface.
>
True, but that doesn't really matter since can decide whether you want 
bytecode or binary for a supported target system and choose/configure the 
compiler to suit.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]


#32667

FromJerry Stuckle <jstucklex@attglobal.net>
Date2015-09-24 22:25 -0400
Message-ID<mu2b7h$f5e$1@dont-email.me>
In reply to#32664
On 9/24/2015 9:15 PM, Martin Gregorie wrote:
> On Thu, 24 Sep 2015 19:40:02 -0400, Jerry Stuckle wrote:
> 
>> No, Java is not compiled into machine code.  Although there are
>> third-party tools which will convert Java into machine code. the Java
>> compiler creates byte code.
>>
> Errr, Java can be compiled into machine code: such compilers exist. GCJ 
> could generate either bytecode or machine code for a quite large range of 
> architectures. I'm only saying 'could' because the website has no news 
> items later than 2009.
>

As I said - there are third-party tools which will convert Java into
machine code.  But the Java compiler creates bytecode.

Do you read what you're responding to?

>> If Java were compiled into machine code, it could not run on multiple
>> platforms under multiple OS's.  The fact it can do that proves it is not
>> machine code - because every platform and every OS has a different
>> machine code interface.
>>
> True, but that doesn't really matter since can decide whether you want 
> bytecode or binary for a supported target system and choose/configure the 
> compiler to suit.
> 
> 

It definitely matters!  If you want the resulting file to be independent
of the hardware platform and OS, you must compile to byte code.
Compiling to machine code limits you to one OS series (or sub-series) on
one hardware platform.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#32675

FromEternal Hope <laughingspam99@gmail.com>
Date2015-09-25 03:46 +0100
Message-ID<mu2cdu$i5a$2@dont-email.me>
In reply to#32659
On 25/09/2015 00:40, Jerry Stuckle wrote:
> On 9/24/2015 4:18 PM, Lew wrote:
>> On Thursday, September 24, 2015 at 12:10:51 PM UTC-7, Eternal Hope wrote:
>>> On 24/09/2015 12:21, Martin Gregorie wrote:
>>>> On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:
>>>>
>>>>> On 24/09/2015 00:10, Lew wrote:
>>>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
>>>>>> wrote:

<snip endless Lew spew>

>> Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C.

Ignoramus


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]


#32690

FromJerry Stuckle <jstucklex@attglobal.net>
Date2015-09-25 09:59 -0400
Message-ID<mu3jsh$dep$2@dont-email.me>
In reply to#32675
On 9/24/2015 10:46 PM, Eternal Hope wrote:
> On 25/09/2015 00:40, Jerry Stuckle wrote:
>> On 9/24/2015 4:18 PM, Lew wrote:
>>> On Thursday, September 24, 2015 at 12:10:51 PM UTC-7, Eternal Hope
>>> wrote:
>>>> On 24/09/2015 12:21, Martin Gregorie wrote:
>>>>> On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:
>>>>>
>>>>>> On 24/09/2015 00:10, Lew wrote:
>>>>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
>>>>>>> wrote:
> 
> <snip endless Lew spew>
> 
>>> Java is compiled. The output of the compiler is run in the machine,
>>> JUST LIKE WITH C.
> 
> Ignoramus
> 
> 

I think you replied to the wrong person.  That was not my comment.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]


#32697

FromEternal Hope <laughingspam99@gmail.com>
Date2015-09-25 15:32 +0100
Message-ID<mu3lqr$k7i$2@dont-email.me>
In reply to#32690
On 25/09/2015 14:59, Jerry Stuckle wrote:
> On 9/24/2015 10:46 PM, Eternal Hope wrote:
>> On 25/09/2015 00:40, Jerry Stuckle wrote:
>>> On 9/24/2015 4:18 PM, Lew wrote:
>>>> On Thursday, September 24, 2015 at 12:10:51 PM UTC-7, Eternal Hope
>>>> wrote:
>>>>> On 24/09/2015 12:21, Martin Gregorie wrote:
>>>>>> On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote:
>>>>>>
>>>>>>> On 24/09/2015 00:10, Lew wrote:
>>>>>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope
>>>>>>>> wrote:
>>
>> <snip endless Lew spew>
>>
>>>> Java is compiled. The output of the compiler is run in the machine,
>>>> JUST LIKE WITH C.
>>
>> Ignoramus
>>
>>
>
> I think you replied to the wrong person.  That was not my comment.
>

Rectified.

-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]


Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.java.programmer


csiph-web