In your original post you list 6 lines of JS code that loads 3 external scripts.
No, no I didn't. I listed the steps the browser took for each technology, in order. Are you at all familiar with the Javascript language? If not, you may want to consider brushing up before you make comparative statements about Java and Javascript. The two serve very different needs and operate in very different fashions.
How is this any different than a webpage that links to an external JS file (as most websites do)?
Did you or did you not just read that huge sequence I spelled out for you two posts ago? You know, the one that showed the exact string of actions that have to happen in order to load a JAR file vs. a set of Javascript files?
In both cases, you need to download the initial JS or JAR file before loading the rest on demand.
You don't need to do any such thing in Javascript. A JAR is a collection of ALL the files in the applet while Javascript loads and executes each file independently. This works because Javascript is a classless language. There is no object called "MyObject" that I need to download a class file for before I can use it. If I want an object in Javascript, I simply create it:
var STATES = {ALIVE: 0, DEAD: 1}; var myobject = {x: 10, y: 10, state: STATES.ALIVE};
I can fit hundreds of such definitions in a very small amount of space. Meanwhile, Java requires one of these for each object type:
public class MyObject {
public static final int STATE_ALIVE = 0;
public static final int STATE_DEAD = 1;
private int x = 0;
private int y = 0;
private int state = STATE_ALIVE;
public int getX() { return x; }
public int setX(int x) { this.x = x; }
public int getY() { return y; }
public int setY(int y) { this.y = y; }
public int getState() { return state; }
public int setState(int state) { this.state = state; } }
As you probably know, you tend to need at least a couple of class files before you can get your program working. Even simple programs often reach a dozen class files or more. Which isn't necessarily a bad thing. Except that with Java, I need to download all of that before my program can start running. Javascript has no need for such gobs of metadata. Which makes it less powerful from a structural perspective, but makes it ideal as a compact web language that can load and execute as the browser loads the page.
You cannot perform those sorts of inlined tasks with Applets. They're not designed for it.
FWIW though, it is possible to use Java as a replacement scripting language for Java. Look up the DOM bridge for Applets and the LiveConnect APIs sometime. If you're clever enough, you should understand how to hand-off control from Javascript to Java. Shortly thereafter, you should come to an understanding of why it is not a practical solution using the current Java runtime.
The JarIndex mechanism collects the contents of all the jar files defined in an applet and stores the information in an index file in the first jar file on the applet's class path. After the first jar file is downloaded, the applet class loader will use the collected content information for efficient downloading of jar files.
Nothing happens until the first JAR is downloaded. Period. End of Story. It does not compare to Javascript in any way, shape, or form.
I should know. I've written more classloaders and designed more AJAX code-loaders than I doubt you and all your coworkers will write in your entire lives. So listen to an old bear when he tells you: Java Applets are disadvantaged for web use.
Yeash. Kids these days. Get off my lawn, will 'ya!:P
See how that happens as part of the page load? Now let's look at a similar Java app:
1. Read <applet src="app.jar" code="a"> 2. Create a new thread and turn over execution to the JVM 3. Download app.jar 4. Read Manifest.mf to load references to any necessary libraries 5. Extract a.class 6. Verify a.class 7. Extract b.class 8. Verify b.class 9. Extract c.class 10. Verify c.class 11. Initialize a.class 12. Initialize b.class 13. Initialize c.class 14. Execute a.class
Somewhere in there the JVM downloads library JARs referenced by app.jar. When this happens and how is dependent on the classloader. It could be during the initial load, or it could be after execution starts. Either way, the entire applet must be downloaded before execution can begin. That's just the nature of the JAR format.
Javascript files are not archived and can be executed on demand. Flash files are written out in an odd linear format that allows for streaming of the file. This allows execution to begin even before the file has completed downloading.
No, the VM loads instantaneously. The applets do not. The applets still take a few seconds to download and initialize the correct APIs. For very small Applets this is a marked difference. For larger applets, the difference is far less apparent. For example, if you run these demos, you get to see two loading screens. The first is the Java plugin generating a loading screen. This takes time while the necessary code is downloaded. Then you get to see the program's loading screen as it loads the necessary data files.
Javascript does not have this problem. No loading screen is necessary because code modules are immediately executed as they are loaded. If I chose to have a loading screen, there will be only one loading screen. But I can choose to begin execution immediately if I so choose. I do not have that choice with a Java JAR. At least, not without creating a sophisticated loader program that (ideally) loads fast enough to avoid the applet loader screen.
While some optimizations were made, the primary thing Sun did was to add a loading screen to replace the classic "gray box" problem. This doesn't actually make anything faster or let the user use the application any earlier. However, it does inform the user that something is happening and that the applet has not crashed.
You seem to be confusing the instruction set with the underlying implementation. Core 2 is awesome. The instruction set is not. So much so that it must be translated into a decent set of instructions by microcode before the processor can pass it through the decoder and ALU.
What is "archaic" about modern x86?
Oh, I don't know. Instructions for 64-bit programming piled upon instructions for 32-bit programming piled upon instructions for 16-bit programming piled upon instructions for 8-bit programming, all with a half-dozen memory modes to choose from, four different register access methods, special use of particular registers in certain modes, complex instructions added willy-nilly only to be deprecated into slow microcode later on, four different SIMD schemes, a few different floating point modes, a variety of segmentation schemes (none of which are used), support for context switching (that no one uses), variable length instructions, etc, etc, etc.
x86 is about the worst instruction set known to man. (Which is kind of amusing when you consider that it became the most used instruction set ever.) Even if we assume that the system will only allow a small subset of x86 code, there is still the very real possibility that it will be impossible to protect against the full ISA when executing code natively. Just off the top of my head, I'm already thinking of carefully crafting instructions so that they seem correct when the verifier passes over them in sequence, but actually execute as different instructions when the jump is executed into what appears to be the middle of an instruction. Oops.
Have you looked at a modern x86 microprocessor's implementation of the x86 ISA?
Yeah, I have. I could kill my cat by accidentally dropping heavy reference manuals sitting on my shelf. The x86 instruction set is far too large, overly complex, redundant, antiquated, and poorly suited as a replacement for VM-targeted instruction sets like Java bytecode.
The only reason to do any of this is speed. You're right, JS is fine for lots of things, but even the best JavaScript JIT won't be as fast as native x86.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." --Donald Knuth
"Speed" is a terrible excuse for attempting a platform like this. Especially when APIs can cover the 3% performance gap that Knuth referred to. I don't need to write a GL renderer in Javascript. I can simply call the necessary APIs to manipulate the native GL instance for me. That's more than fast enough for compute-intensive graphics.
For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing.
Or you could write an application that downloads the photo into the browser and manipulates it in a Canvas. It's not like these APIs are any huge secret. You'd think that someone working for Google would know about that. I won't even get into using the ubiquitous Flash 9 plugin to accomplish the same goal.
Strong typing means 1 + "2" is nonsense, and you have to explicitly convert the types.
That example has nothing to do with strong typing, but rather operator overloading. Both Java and Javascript understand "+" to be a string concatenation symbol when dealing with strings. Thus they attempt to coerce the values into strings. In Java's case, the resulting output looks something like this:
new StringBuffer().append(String.valueOf(1)).append("2");
Javascript does have implicit type casting (e.g. '1' - 1 = 0), but this is a feature that can be found in quite a few strongly languages. (e.g. int x = 10; char val = 10; x += val) Javascript is actually STRONGER than C when it comes to typing. When I cast a variable to a new type, its original type information is redefined and/or completely lost. This can create problems when programmers start using (void *) pointers for everything. Javascript remembers the underlying type of a value at all times. Values are never modified or destroyed, but can be coerced to create a new value with an implicitly cast type.
Does anyone actually enjoy programming JavaScript?
I do. And so can you. It's the C-based syntax that throws most programmers for a loop. Once you realize that the language is actually of a functional design similar to LISP, everything gets a lot easier.
No real objects, weak typing, etc.
Javascript has one of the most flexible Object systems I have seen in my 20+ years of programming. And its typing system is actually quite strong. Like another poster mentioned, it's dynamically typed not weakly typed. Which is an issue that fades into obscurity once you understand how to properly utilize the language.
It's fine for small bits of code, but for larger apps? Ugh.
Javascript (like most functional languages) is perfect for building large apps out of a massive number of small bits. Look up scoping in Javascript sometime and you'll understand that larger apps get built by having machines within machines within machines to go from simple tasks to ever more complex tasks. It is, in many ways, a more scalable solution than APIs and packaging. But it is different and therein lies the crux of its failure in the minds of many programmers.
The only problem you seem to have with Java plugins is the load time -- this is only resolved by Javascript because JS is pre-loaded by the browser at all times (in modern browsers at least).
The Java runtime was compiled into early browsers like Netscape. So the load time is not caused by the plugin itself. (Though that does play a role in the first activation.) The load time is the time it takes to download the complete application, dearchive the components, load the components into an interpreter or JIT, initialize the environment and/or APIs used, and finally present the application to the user.
Javascript fits in better with the way web browsers are designed in that the browser executes each individual module during the page load. The makes page loading more asynchronous and thus a better experience for the web user. The web developer can still throw up a "loading" progress bar for applications must preload, but they are the exception rather than the rule.
Making a browser that integrates Java in a reasonable way and makes it work just as seamlessly as Javascript was tried already (by Netscape) but it was before we had computers with enough RAM to handle it IMHO.
There is more to the issue than meets the eye. Besides the synchronous aspect I mentioned, the client Java runtime has also grown to meet the expansion in system memory and complexity. Which is a good thing from the perspective of writing rich applications for deployment on the server or desktop. It's a bad thing when we're talking about the time-sensitive environment of the web browser. If you want an ideal JVM for the browser, Sun is going to have to strip it down again and make the platform a better fit than it has been in the past. (A version that relies heavily on the DOM for APIs would be preferable.)
They're also going to have to work out a good method of solving the load problem. Even Flash allows for partial execution prior to the load being complete. (This is how most Flash games show a LOADING screen.) Java was not designed with this in mind and the platform shows it. There are ways a developer could work around it using dynamic class loading, but this requires a great deal of knowledge, effort, and skill on the part of the developer.
My own feeling is that it's best to let sleeping dogs lie. I love the Java platform, but it currently has a higher calling. Best to let it work where it excels and focus on the aspects of the browser that currently excel. (e.g. Javascript)
Why not? It just means that the permissible instruction sequences are limited to a subset that can be statically analyzed and verified to be safe. The Java VM has similar verification algorithms that are run whenever untrusted code is first loaded.
One of the key differences is that Java code and data are separated to the point of paranoia. I cannot load a classfile as data and pass through execution to the native system. With the x86 instruction set, I can load a data file and execute a jump to a data segment without the code having passed through any sort of system loader. A VM would have to take this into account. Not to mention common issues of stack smashing, heap overflows, and other common memory tricks to execute unwanted code.
When you're managing native code, it only takes one slip-up to hand over the keys to the kingdom. That slip-up may be as simple as a two byte exploit, but it's a slip-up none the less. One must be VERY careful with native code because there is no way to prove that it is safe to execute natively.
Hypervisor features in modern processors simplify the issue somewhat, but it is still not proven that hypervisors are without exploits. Not to mention the overhead of running dozens of simultaneous hypervisor environments.
Java and Javascript have it right. Java bytecode is provably correct because it targets an ideal machine. Thus the code can be translated into well-behaved native code with the linkage between data and code managed during or after translation. Javascript is just as good because it provides an abstract execution environment that must rely on exposed APIs to accomplish any interaction with the system. It is provable not possible (shy of an underlying flaw in the browser) for Javascript to break through its execution engine into a native runtime.
The two platforms may be paranoid, but when you're dealing with security on the scale of the World Wide Web, "better safe than sorry" is a good motto.
Google has announced its Google native client, which enables x86 native code to be run securely inside a browser.
Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it. An instruction set that was finally starting to loosen its grip as the industry worked toward more abstract solutions.
With Java applets already dead and buried
And with good reason!!! Plugin engines do not provide a very smooth browsing experience. You must wait for them to download and activate before you can start using the widget. Meanwhile, Javascript is designed for execution as the page is loading.
The heavyweight JVM was probably the worst offender, but look at Flash for another example of an engine that most developers would rather eliminate. While it was hip to create entire websites out of Flash for a while, the platform was very user-unfriendly and almost died out. Thanks to infighting over video standards however, Flash was able to hold on as a video delivery platform and even gained a margin of success as a web-gaming platform. (About the only area where Java Applets really shined back when they were popular.)
My personal opinion* is that this is a step in the wrong direction. Javascript engines are getting good. Damn good. I'd like to see more R&D poured into these engines and the underlying technologies rather than reinventing ActiveX and Java. If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.
*...and 50 cents won't buy you a cup of coffee anymore, so take it for what it's worth.
** As an aside, C/C++ is an incredibly complex build environment. Why anyone would want to continue subjecting developers to the angst of compiler differences, makefiles, configure scripts, and other irritants is beyond me. As is typical with such platforms, I can't even get the examples running on my machine. The run.py script dies with an "Invalid Argument" on line 42 and the nacl-gcc compiler fails with syntax errors a-plenty. I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?
In Soviet Russia.... well, I have no idea what they call their underclothes, but I'm sure it has something to do with the underclothes wearing YOU. Or something like that.
After WWII, Russia ended up with tons of German clothes as part of the spoils of war. Not being familiar with the styles of clothing worn in Germany, many women were seen using German undergarments as evening gowns. (e.g. going to the Opera, a ball, or a fancy party) For the most part no one noticed the difference, but those that were more familiar with German life were amused to no end.
I have sort of a 'meh' reaction to it. It's not that the technology isn't cool, but it's a solution looking for a problem. Much like Silverlight, but without the antitrust practices to force it into use. In particular, its intended use as a platform on top of applets bothers me. Applets died out for a lot of good reasons. There's no good argument to be made for their revival. Especially with Flash and/or DHTML providing nearly all the advantages of Applets. Just let sleeping dogs lie and focus on using the technology elsewhere.
There is a possibility that JavaFX could be useful on cell phones. However, I don't see it happening. Sun is good at creating abstract technologies that provide options to the market. They're not so good at creating firm solutions that can hold their own in a competitive environment. The competition may be technologically inferior, but at least their end to end solution is practical.
Which is what I'm seeing with cell phones. Android may be only pseudo-Java based, but it provides the necessary phone technology top to bottom. The amount of customization necessary is pretty minimal. Meanwhile, Sun is pushing this JavaFX technology which is only a small piece of the puzzle. (Arguably the least important piece!) Handset manufacturers would have to adapt their phone software to meet the technology rather than having a pre-rolled solution available. Thus there's not much incentive to ship JavaFX.
In effect, JavaFX is DOA. You can throw it on the pile with PalmOS Cobalt, Shockwave, VRML, and other interesting technologies that failed to properly position themselves in the marketplace.
FWIW, I'm flattered you consider my opinion important enough to ask.:-)
My main problem is..."include standardized, cross-platform audio and video playback code (in the form of On2 licensed codecs)"
On2 is the company that provides the video/audio codecs for video in the Flash plugin. (i.e. The technology used by sites like Youtube.) The inclusion of these codecs in JavaFX means that JavaFX will be able to play movies intended for a Flash player.
And..."The development kit currently consists of the base run-time, a NetBeans/Eclipse plug-in and a set of artifact exporters for Adobe CS 3&4."
In other words, JavaFX is a scripting language for graphics. Similar in principle to Flash. The download gives developers the necessary libraries and viewers to develop JavaFX code. (Including plugins for your favorite IDE.) Not sure what the Adobe CS stuff is about.
...are they implying that Microsoft has something to do with this?
From an earlier Groklaw article:
On the theme of folks piling on Apple lately, here's a new lawsuit against Apple, claiming Apple is trying to monopolize MP3s. And here's another, complaining about monopoly again and how Apple is such a meanie for not letting iTunes play Microsoft's DRM-encrusted format, Windows Media Audio. I've come to the conclusion, personally, that if you compete against Microsoft and start to win, you get sued by litigants who suddenly care about stuff only Microsoft can possibly care about. Speaking of monopolies. Complaining that iTunes on the iPod doesn't support Microsoft DRM doesn't pass my sniff test. I simply do not believe there is a customer in the world that would sue over that.
Just my opinion, folks. But I confess when I see a lawsuit complaining that DRM won't play, I start to wonder who might really care about that. I know I don't. I don't know anyone who cares about that, actually. That's what vendors fall in love with, not customers. Maybe in an alternative universe. And lookee here. The plaintiff is a lawyer. Well.
P.J. definitely has a point here. As such, Apple may have a point in their filing. The question is, how far abstracted from Psystar are the parties that Apple is really looking for?
Safe out of the box... that is until a user starts clicking on things.
Even after the user starts clicking on things, Macs are generally safe. The user must explicitly punch holes in their system to create most vulnerabilities.
Honestly, the original tech note struck me as an attempt by Apple to say something that Apple politically couldn't say: Mac antivirus software primarily protects against Windows viruses. If Windows exists on your network or runs on your Mac via virtualization, your windows systems will be safer if you run Mac antiviral software. (Macs can't get infected, but they can be carriers!) Thus running antiviral software is a "good idea" and presents "one more program" that must be defeated.
Of course, once the press got wind of this poorly worded tech note, it made more sense for Apple to simply pull it rather than take the political hit of wording it correctly.
I think part of it is that building browsers on Trident has fallen out of favor. There used to be quite a few such browsers out there, but most of them have disappeared. Probably because they are unable to compete against the IE == The Internet mentality. Mac users seem to have less of that Safari == The Internet association, so they're more open to alternative browsers.
Personally, I'm not really sure this article adds much. You still have four major browser engines: Trident (IE/Microsoft), Gecko (Mozilla), Webkit (Apple), and Presto (Opera). Nearly all web browsers are based on one of those four engines. Which limits the choice based of better web experience to primarily the user interface. Since the major browser makers are already tussling over the best interface to wrap around their engine, there's not much to differentiate the third party browsers.
Dijkstra talks about software engineering in the paper and says its charter is "How to program if you cannot".
A lot has changed since Dijkstra wrote his paper. A real need for systems based on off the shelf technology has developed in the marketplace. Thus a software engineer is to a computer scientist what a building engineer is to a physicist. The engineer uses the theorems of the scientist to accomplish his task, but he does not himself work toward the furthering of science.
In Dijkstra's time, computers tended to be massive beasts that were deployed with a small army of programmers and hardware specialists to maintain. COBOL programmers were not programmers in the truest sense, but rather business analysts who translated business rules into instructions a computer could understand. The engineering had already been done by real computer scientists.
Such is no longer the case. If I wish to deploy a complex web application, it needs to be properly engineered to handle the volume, to scale as needed, to account for I/O bottlenecks, to ensure intelligent action in the case of network failure, to provide secure access, and a host of other common issues. The needs of such development go far beyond the confines of "purchase a mainframe and attach terminals and printers". Real planning and engineering has to go into everything from choosing the servers, the database technology, the application platform, supporting technologies, and even (more recently) the performance of the Javascript that runs in the user's browser.
As such, I honestly think that computer science and software engineering should be split off into separate disciplines. Right now, very few people understand the difference. Software engineering is very much a trade that can be taught as a form of applied computer science. Computer science is still about furthering the understanding of information, the mathematics behind it, algorithms to improve efficiency, and the methods by which the logic can be expressed in the real world. (I recommend a minor in quantum physics if you plan to develop new computational machines!)
My gf routinely has the SD, rather than HD, version of various TV channels on because evidently from her point of view there is no discernable difference. This is a 42" plasma from about 4 metres away.
I can tell the difference, and I don't care too much about the quality improvement. The primary reason I like the digital channels is that they are true 16:9 widescreen. Opening up the edges of the scene makes a much bigger difference than the horizontal resolution, as far as I'm concerned.
Of course, that only applies to regular television shows. Camera operators have been trained for decades to keep the camera tight on the subjects. Thus the extra detail is not needed. If you're talking about a complex scene like sports, however, all bets are off. I don't usually watch football (save for the Superbowl), but even a blind man can tell that an HD picture shows you more of the action than an SD picture.:-)
BTW, one reason why many people can't tell the difference is that the LCD or Plasma screens are already WAY sharper than the CRTs people used to watch. In result, even an SD signal looks a lot better. (Unless you're playing video games. Then SD looks worse.)
It's really quite simple: Teenagers buy most video games. Teenagers don't have investments and mortgages that tanked nor are they good at saving instead of spending.
Teenagers have not bought the most video games in quite a long time. In fact, the average age is 30 with 65% of game players over the age of 18. If the video game industry were to see a drop in buyers over the age of 18, they would suffer just as greatly as the rest of the economy.
I know the entertainment aspect may seem like too easy of an answer, but the historical data does support it.
During the beginning of the Great Depression, one of the most popular forms of entertainment was dancing. It usually only cost a few cents to get into a dance hall. Once there, the dancer could remain for most of the night. This was so economical that it led to a new form of sport: Marathon Dancing.
At first this extreme form of dancing was done to achieve new records. Then the dance halls started to get in on the act, and began promoting competitions. Soon, dancers would be on the floor for months at a time, with only 15 minute breaks every hour or so. (Yes, 24x7 on the floor. They slept like wolves at best!) These long marathons gave dance halls the opportunity to encourage or stage situations worthy of a soap-opera. Fights broke out, relationships came and went, people struggled not to lose their cool over the grinding months, and even weddings were performed on the floor!
The public just ate this stuff up. They spent their nickels to visit these dance halls for entertainment. If they were hungry enough, they might even try their hand at a marathon. While the lack of sleep was a killer, dance halls regularly served 12 meals a day! Quite a difference from standing in a bread line for a meager meal.
Eventually, dance was replaced with another non-stop form of entertainment: Movies.
You know the stereotype of the Bell Boy with his flashlight leading people into the dark theater? Well, there's good reason for that. Back during the depression, the movies never stopped! For a mere nickel you could visit the movies and watch for hours before it looped back to something you had seen before. News reels, Comedies, Cartoons, Features, etc. It was a true potpourri of entertainment. And since there was no television to compete, visiting the theater was one of the best ways of keeping abreast of the latest news and entertainment.
Speaking of television, yet another form of entertainment took a bite out of the market during the Depression. Radio saw a surge in public life. From comedy, to the original soap operas, to FDR's Fireside Chats, to Late Breaking News, to Orson Wells' War of The Worlds broadcast, radio was an incredible escape from the ugliness of everyday life. And every family who could manage to scrape together enough money had one.
I won't bore you with further details, but such a trend for escapist entertainment is seen throughout modern history. The worse things get, the more we turn to outlets for escape. With television on the decline, I see absolutely no reason why consumers would not find value in Video Games. They are the newest and hottest form of escapist medium. Eventually they too will be replaced by a new medium, but for now it's reasonably safe to bet on video games during any period of strong economic downturn.:-)
Slashdot Mirror
No, no I didn't. I listed the steps the browser took for each technology, in order. Are you at all familiar with the Javascript language? If not, you may want to consider brushing up before you make comparative statements about Java and Javascript. The two serve very different needs and operate in very different fashions.
Did you or did you not just read that huge sequence I spelled out for you two posts ago? You know, the one that showed the exact string of actions that have to happen in order to load a JAR file vs. a set of Javascript files?
You don't need to do any such thing in Javascript. A JAR is a collection of ALL the files in the applet while Javascript loads and executes each file independently. This works because Javascript is a classless language. There is no object called "MyObject" that I need to download a class file for before I can use it. If I want an object in Javascript, I simply create it:
I can fit hundreds of such definitions in a very small amount of space. Meanwhile, Java requires one of these for each object type:
As you probably know, you tend to need at least a couple of class files before you can get your program working. Even simple programs often reach a dozen class files or more. Which isn't necessarily a bad thing. Except that with Java, I need to download all of that before my program can start running. Javascript has no need for such gobs of metadata. Which makes it less powerful from a structural perspective, but makes it ideal as a compact web language that can load and execute as the browser loads the page.
Even more interesting is that I can do this:
You cannot perform those sorts of inlined tasks with Applets. They're not designed for it.
FWIW though, it is possible to use Java as a replacement scripting language for Java. Look up the DOM bridge for Applets and the LiveConnect APIs sometime. If you're clever enough, you should understand how to hand-off control from Javascript to Java. Shortly thereafter, you should come to an understanding of why it is not a practical solution using the current Java runtime.
With all due respect friend, you need to actually read your own links.
http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#JAR%20Index
Nothing happens until the first JAR is downloaded. Period. End of Story. It does not compare to Javascript in any way, shape, or form.
I should know. I've written more classloaders and designed more AJAX code-loaders than I doubt you and all your coworkers will write in your entire lives. So listen to an old bear when he tells you: Java Applets are disadvantaged for web use.
Yeash. Kids these days. Get off my lawn, will 'ya! :P
I'll put this as simply as I can. Javascript execution is like this:
1. Read <script src="a.js">
2. Execute a.js
3. Read <script src="b.js">
4. Execute b.js
5. Read <script src="c.js">
6. Execute c.js
See how that happens as part of the page load? Now let's look at a similar Java app:
1. Read <applet src="app.jar" code="a">
2. Create a new thread and turn over execution to the JVM
3. Download app.jar
4. Read Manifest.mf to load references to any necessary libraries
5. Extract a.class
6. Verify a.class
7. Extract b.class
8. Verify b.class
9. Extract c.class
10. Verify c.class
11. Initialize a.class
12. Initialize b.class
13. Initialize c.class
14. Execute a.class
Somewhere in there the JVM downloads library JARs referenced by app.jar. When this happens and how is dependent on the classloader. It could be during the initial load, or it could be after execution starts. Either way, the entire applet must be downloaded before execution can begin. That's just the nature of the JAR format.
Javascript files are not archived and can be executed on demand. Flash files are written out in an odd linear format that allows for streaming of the file. This allows execution to begin even before the file has completed downloading.
No, the VM loads instantaneously. The applets do not. The applets still take a few seconds to download and initialize the correct APIs. For very small Applets this is a marked difference. For larger applets, the difference is far less apparent. For example, if you run these demos, you get to see two loading screens. The first is the Java plugin generating a loading screen. This takes time while the necessary code is downloaded. Then you get to see the program's loading screen as it loads the necessary data files.
Javascript does not have this problem. No loading screen is necessary because code modules are immediately executed as they are loaded. If I chose to have a loading screen, there will be only one loading screen. But I can choose to begin execution immediately if I so choose. I do not have that choice with a Java JAR. At least, not without creating a sophisticated loader program that (ideally) loads fast enough to avoid the applet loader screen.
While some optimizations were made, the primary thing Sun did was to add a loading screen to replace the classic "gray box" problem. This doesn't actually make anything faster or let the user use the application any earlier. However, it does inform the user that something is happening and that the applet has not crashed.
Perceptual performance FTW! ;-)
You seem to be confusing the instruction set with the underlying implementation. Core 2 is awesome. The instruction set is not. So much so that it must be translated into a decent set of instructions by microcode before the processor can pass it through the decoder and ALU.
Oh, I don't know. Instructions for 64-bit programming piled upon instructions for 32-bit programming piled upon instructions for 16-bit programming piled upon instructions for 8-bit programming, all with a half-dozen memory modes to choose from, four different register access methods, special use of particular registers in certain modes, complex instructions added willy-nilly only to be deprecated into slow microcode later on, four different SIMD schemes, a few different floating point modes, a variety of segmentation schemes (none of which are used), support for context switching (that no one uses), variable length instructions, etc, etc, etc.
x86 is about the worst instruction set known to man. (Which is kind of amusing when you consider that it became the most used instruction set ever.) Even if we assume that the system will only allow a small subset of x86 code, there is still the very real possibility that it will be impossible to protect against the full ISA when executing code natively. Just off the top of my head, I'm already thinking of carefully crafting instructions so that they seem correct when the verifier passes over them in sequence, but actually execute as different instructions when the jump is executed into what appears to be the middle of an instruction. Oops.
Yeah, I have. I could kill my cat by accidentally dropping heavy reference manuals sitting on my shelf. The x86 instruction set is far too large, overly complex, redundant, antiquated, and poorly suited as a replacement for VM-targeted instruction sets like Java bytecode.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." --Donald Knuth
"Speed" is a terrible excuse for attempting a platform like this. Especially when APIs can cover the 3% performance gap that Knuth referred to. I don't need to write a GL renderer in Javascript. I can simply call the necessary APIs to manipulate the native GL instance for me. That's more than fast enough for compute-intensive graphics.
Um... what?
That's always worked in Java. Are feeling alright, son?
Or you could write an application that downloads the photo into the browser and manipulates it in a Canvas. It's not like these APIs are any huge secret. You'd think that someone working for Google would know about that. I won't even get into using the ubiquitous Flash 9 plugin to accomplish the same goal.
As you said, their example is AWFUL.
That example has nothing to do with strong typing, but rather operator overloading. Both Java and Javascript understand "+" to be a string concatenation symbol when dealing with strings. Thus they attempt to coerce the values into strings. In Java's case, the resulting output looks something like this:
Javascript does have implicit type casting (e.g. '1' - 1 = 0), but this is a feature that can be found in quite a few strongly languages. (e.g. int x = 10; char val = 10; x += val) Javascript is actually STRONGER than C when it comes to typing. When I cast a variable to a new type, its original type information is redefined and/or completely lost. This can create problems when programmers start using (void *) pointers for everything. Javascript remembers the underlying type of a value at all times. Values are never modified or destroyed, but can be coerced to create a new value with an implicitly cast type.
I do. And so can you. It's the C-based syntax that throws most programmers for a loop. Once you realize that the language is actually of a functional design similar to LISP, everything gets a lot easier.
Javascript has one of the most flexible Object systems I have seen in my 20+ years of programming. And its typing system is actually quite strong. Like another poster mentioned, it's dynamically typed not weakly typed. Which is an issue that fades into obscurity once you understand how to properly utilize the language.
Javascript (like most functional languages) is perfect for building large apps out of a massive number of small bits. Look up scoping in Javascript sometime and you'll understand that larger apps get built by having machines within machines within machines to go from simple tasks to ever more complex tasks. It is, in many ways, a more scalable solution than APIs and packaging. But it is different and therein lies the crux of its failure in the minds of many programmers.
The Java runtime was compiled into early browsers like Netscape. So the load time is not caused by the plugin itself. (Though that does play a role in the first activation.) The load time is the time it takes to download the complete application, dearchive the components, load the components into an interpreter or JIT, initialize the environment and/or APIs used, and finally present the application to the user.
Javascript fits in better with the way web browsers are designed in that the browser executes each individual module during the page load. The makes page loading more asynchronous and thus a better experience for the web user. The web developer can still throw up a "loading" progress bar for applications must preload, but they are the exception rather than the rule.
There is more to the issue than meets the eye. Besides the synchronous aspect I mentioned, the client Java runtime has also grown to meet the expansion in system memory and complexity. Which is a good thing from the perspective of writing rich applications for deployment on the server or desktop. It's a bad thing when we're talking about the time-sensitive environment of the web browser. If you want an ideal JVM for the browser, Sun is going to have to strip it down again and make the platform a better fit than it has been in the past. (A version that relies heavily on the DOM for APIs would be preferable.)
They're also going to have to work out a good method of solving the load problem. Even Flash allows for partial execution prior to the load being complete. (This is how most Flash games show a LOADING screen.) Java was not designed with this in mind and the platform shows it. There are ways a developer could work around it using dynamic class loading, but this requires a great deal of knowledge, effort, and skill on the part of the developer.
My own feeling is that it's best to let sleeping dogs lie. I love the Java platform, but it currently has a higher calling. Best to let it work where it excels and focus on the aspects of the browser that currently excel. (e.g. Javascript)
One of the key differences is that Java code and data are separated to the point of paranoia. I cannot load a classfile as data and pass through execution to the native system. With the x86 instruction set, I can load a data file and execute a jump to a data segment without the code having passed through any sort of system loader. A VM would have to take this into account. Not to mention common issues of stack smashing, heap overflows, and other common memory tricks to execute unwanted code.
When you're managing native code, it only takes one slip-up to hand over the keys to the kingdom. That slip-up may be as simple as a two byte exploit, but it's a slip-up none the less. One must be VERY careful with native code because there is no way to prove that it is safe to execute natively.
Hypervisor features in modern processors simplify the issue somewhat, but it is still not proven that hypervisors are without exploits. Not to mention the overhead of running dozens of simultaneous hypervisor environments.
Java and Javascript have it right. Java bytecode is provably correct because it targets an ideal machine. Thus the code can be translated into well-behaved native code with the linkage between data and code managed during or after translation. Javascript is just as good because it provides an abstract execution environment that must rely on exposed APIs to accomplish any interaction with the system. It is provable not possible (shy of an underlying flaw in the browser) for Javascript to break through its execution engine into a native runtime.
The two platforms may be paranoid, but when you're dealing with security on the scale of the World Wide Web, "better safe than sorry" is a good motto.
Because all that we need is to further promote an archaic instruction set that won't die because of all the pre-existing code compiled for it. An instruction set that was finally starting to loosen its grip as the industry worked toward more abstract solutions.
And with good reason!!! Plugin engines do not provide a very smooth browsing experience. You must wait for them to download and activate before you can start using the widget. Meanwhile, Javascript is designed for execution as the page is loading.
The heavyweight JVM was probably the worst offender, but look at Flash for another example of an engine that most developers would rather eliminate. While it was hip to create entire websites out of Flash for a while, the platform was very user-unfriendly and almost died out. Thanks to infighting over video standards however, Flash was able to hold on as a video delivery platform and even gained a margin of success as a web-gaming platform. (About the only area where Java Applets really shined back when they were popular.)
My personal opinion* is that this is a step in the wrong direction. Javascript engines are getting good. Damn good. I'd like to see more R&D poured into these engines and the underlying technologies rather than reinventing ActiveX and Java. If researchers wanted to invent a more efficient or usable browser language other than JS, I'd be all for it. But I don't run a browser to become a part of a compute farm. I run a browser to access web information and applications. Very little of which is compute-intensive enough to require a new execution engine over a more advanced set of APIs.
* ...and 50 cents won't buy you a cup of coffee anymore, so take it for what it's worth.
** As an aside, C/C++ is an incredibly complex build environment. Why anyone would want to continue subjecting developers to the angst of compiler differences, makefiles, configure scripts, and other irritants is beyond me. As is typical with such platforms, I can't even get the examples running on my machine. The run.py script dies with an "Invalid Argument" on line 42 and the nacl-gcc compiler fails with syntax errors a-plenty. I'm sure I'll figure it out eventually, but WHY oh why do we want to promote such a complicated method of compiling code?
After WWII, Russia ended up with tons of German clothes as part of the spoils of war. Not being familiar with the styles of clothing worn in Germany, many women were seen using German undergarments as evening gowns. (e.g. going to the Opera, a ball, or a fancy party) For the most part no one noticed the difference, but those that were more familiar with German life were amused to no end.
I have sort of a 'meh' reaction to it. It's not that the technology isn't cool, but it's a solution looking for a problem. Much like Silverlight, but without the antitrust practices to force it into use. In particular, its intended use as a platform on top of applets bothers me. Applets died out for a lot of good reasons. There's no good argument to be made for their revival. Especially with Flash and/or DHTML providing nearly all the advantages of Applets. Just let sleeping dogs lie and focus on using the technology elsewhere.
There is a possibility that JavaFX could be useful on cell phones. However, I don't see it happening. Sun is good at creating abstract technologies that provide options to the market. They're not so good at creating firm solutions that can hold their own in a competitive environment. The competition may be technologically inferior, but at least their end to end solution is practical.
Which is what I'm seeing with cell phones. Android may be only pseudo-Java based, but it provides the necessary phone technology top to bottom. The amount of customization necessary is pretty minimal. Meanwhile, Sun is pushing this JavaFX technology which is only a small piece of the puzzle. (Arguably the least important piece!) Handset manufacturers would have to adapt their phone software to meet the technology rather than having a pre-rolled solution available. Thus there's not much incentive to ship JavaFX.
In effect, JavaFX is DOA. You can throw it on the pile with PalmOS Cobalt, Shockwave, VRML, and other interesting technologies that failed to properly position themselves in the marketplace.
FWIW, I'm flattered you consider my opinion important enough to ask. :-)
It is. This is really a set of libraries on top of the existing Java runtime that support the JavaFX scripting framework.
I'm sure they will once the technology has been shaken out a bit. Sun tends to be cautious about making changes to the core APIs.
On2 is the company that provides the video/audio codecs for video in the Flash plugin. (i.e. The technology used by sites like Youtube.) The inclusion of these codecs in JavaFX means that JavaFX will be able to play movies intended for a Flash player.
In other words, JavaFX is a scripting language for graphics. Similar in principle to Flash. The download gives developers the necessary libraries and viewers to develop JavaFX code. (Including plugins for your favorite IDE.) Not sure what the Adobe CS stuff is about.
From an earlier Groklaw article:
http://www.groklaw.net/article.php?story=20081019133549359
P.J. definitely has a point here. As such, Apple may have a point in their filing. The question is, how far abstracted from Psystar are the parties that Apple is really looking for?
Even after the user starts clicking on things, Macs are generally safe. The user must explicitly punch holes in their system to create most vulnerabilities.
Honestly, the original tech note struck me as an attempt by Apple to say something that Apple politically couldn't say: Mac antivirus software primarily protects against Windows viruses. If Windows exists on your network or runs on your Mac via virtualization, your windows systems will be safer if you run Mac antiviral software. (Macs can't get infected, but they can be carriers!) Thus running antiviral software is a "good idea" and presents "one more program" that must be defeated.
Of course, once the press got wind of this poorly worded tech note, it made more sense for Apple to simply pull it rather than take the political hit of wording it correctly.
I think part of it is that building browsers on Trident has fallen out of favor. There used to be quite a few such browsers out there, but most of them have disappeared. Probably because they are unable to compete against the IE == The Internet mentality. Mac users seem to have less of that Safari == The Internet association, so they're more open to alternative browsers.
Personally, I'm not really sure this article adds much. You still have four major browser engines: Trident (IE/Microsoft), Gecko (Mozilla), Webkit (Apple), and Presto (Opera). Nearly all web browsers are based on one of those four engines. Which limits the choice based of better web experience to primarily the user interface. Since the major browser makers are already tussling over the best interface to wrap around their engine, there's not much to differentiate the third party browsers.
A lot has changed since Dijkstra wrote his paper. A real need for systems based on off the shelf technology has developed in the marketplace. Thus a software engineer is to a computer scientist what a building engineer is to a physicist. The engineer uses the theorems of the scientist to accomplish his task, but he does not himself work toward the furthering of science.
In Dijkstra's time, computers tended to be massive beasts that were deployed with a small army of programmers and hardware specialists to maintain. COBOL programmers were not programmers in the truest sense, but rather business analysts who translated business rules into instructions a computer could understand. The engineering had already been done by real computer scientists.
Such is no longer the case. If I wish to deploy a complex web application, it needs to be properly engineered to handle the volume, to scale as needed, to account for I/O bottlenecks, to ensure intelligent action in the case of network failure, to provide secure access, and a host of other common issues. The needs of such development go far beyond the confines of "purchase a mainframe and attach terminals and printers". Real planning and engineering has to go into everything from choosing the servers, the database technology, the application platform, supporting technologies, and even (more recently) the performance of the Javascript that runs in the user's browser.
As such, I honestly think that computer science and software engineering should be split off into separate disciplines. Right now, very few people understand the difference. Software engineering is very much a trade that can be taught as a form of applied computer science. Computer science is still about furthering the understanding of information, the mathematics behind it, algorithms to improve efficiency, and the methods by which the logic can be expressed in the real world. (I recommend a minor in quantum physics if you plan to develop new computational machines!)
I'm holding out for Gravy Trader myself. I heard the review copies got a score of 101%!
I'm sure I can find a review copy on a Bit Torrent site, but alas! I have no hands.
I can tell the difference, and I don't care too much about the quality improvement. The primary reason I like the digital channels is that they are true 16:9 widescreen. Opening up the edges of the scene makes a much bigger difference than the horizontal resolution, as far as I'm concerned.
Of course, that only applies to regular television shows. Camera operators have been trained for decades to keep the camera tight on the subjects. Thus the extra detail is not needed. If you're talking about a complex scene like sports, however, all bets are off. I don't usually watch football (save for the Superbowl), but even a blind man can tell that an HD picture shows you more of the action than an SD picture. :-)
BTW, one reason why many people can't tell the difference is that the LCD or Plasma screens are already WAY sharper than the CRTs people used to watch. In result, even an SD signal looks a lot better. (Unless you're playing video games. Then SD looks worse.)
Teenagers have not bought the most video games in quite a long time. In fact, the average age is 30 with 65% of game players over the age of 18. If the video game industry were to see a drop in buyers over the age of 18, they would suffer just as greatly as the rest of the economy.
I know the entertainment aspect may seem like too easy of an answer, but the historical data does support it.
During the beginning of the Great Depression, one of the most popular forms of entertainment was dancing. It usually only cost a few cents to get into a dance hall. Once there, the dancer could remain for most of the night. This was so economical that it led to a new form of sport: Marathon Dancing.
At first this extreme form of dancing was done to achieve new records. Then the dance halls started to get in on the act, and began promoting competitions. Soon, dancers would be on the floor for months at a time, with only 15 minute breaks every hour or so. (Yes, 24x7 on the floor. They slept like wolves at best!) These long marathons gave dance halls the opportunity to encourage or stage situations worthy of a soap-opera. Fights broke out, relationships came and went, people struggled not to lose their cool over the grinding months, and even weddings were performed on the floor!
The public just ate this stuff up. They spent their nickels to visit these dance halls for entertainment. If they were hungry enough, they might even try their hand at a marathon. While the lack of sleep was a killer, dance halls regularly served 12 meals a day! Quite a difference from standing in a bread line for a meager meal.
Eventually, dance was replaced with another non-stop form of entertainment: Movies.
You know the stereotype of the Bell Boy with his flashlight leading people into the dark theater? Well, there's good reason for that. Back during the depression, the movies never stopped! For a mere nickel you could visit the movies and watch for hours before it looped back to something you had seen before. News reels, Comedies, Cartoons, Features, etc. It was a true potpourri of entertainment. And since there was no television to compete, visiting the theater was one of the best ways of keeping abreast of the latest news and entertainment.
Speaking of television, yet another form of entertainment took a bite out of the market during the Depression. Radio saw a surge in public life. From comedy, to the original soap operas, to FDR's Fireside Chats, to Late Breaking News, to Orson Wells' War of The Worlds broadcast, radio was an incredible escape from the ugliness of everyday life. And every family who could manage to scrape together enough money had one.
I won't bore you with further details, but such a trend for escapist entertainment is seen throughout modern history. The worse things get, the more we turn to outlets for escape. With television on the decline, I see absolutely no reason why consumers would not find value in Video Games. They are the newest and hottest form of escapist medium. Eventually they too will be replaced by a new medium, but for now it's reasonably safe to bet on video games during any period of strong economic downturn. :-)