If you only write a spec, then implement, then change the spec and reimplement again in short cycles, then the spec can serve nothing more as a description one abstraction level higher than the actual code itself, instead of being a planning device with long-term stability.
I'm not sure what is wrong with that. A spec should settle down into something stable in the long term.
This seems to be the case in most western populations. Life expectancy isn't going up because people are starting to 120, it's going up because infant mortality is coming down.
This simply isn't true. There have been advances in the understanding of heath and the affect of lifestyle on longevity. Fewer people smoke, we generally eat a better diet and we have effective treatments for systemic conditions such as high blood pressure. This means that fewer people are dying in their 50s and 60s of heart disease and cancer.
The proof of increased lifespan (and not just lack of infant mortality) is the potential crisis in pensions in the western world. People were expected to live only 5-10 years after retirement. People now routinely live 20-25 years and some even 30 or more.
I was amazed to hear that there is an Applet API for DOM interaction. Is there any work to make this cross browser compatible?
It already is! There was an API that was introduced for Netscape, but it was extended by Sun to allow JavaScript and DOM interaction for all modern browsers (although there are some differences). It is called LiveConnect, and provides netscape.* packages for applets.
Java Applet technology has changed beyond recognition in the past few years - I find the idea of Java Applet interaction with JavaScript and AJAX to be very exciting and powerful.
I can see how something like this could make an excellent "Web 2.0" ish version that didn't rely on redoing every page in Java Script (thus creating a nightmare of code to support) It seems like you could build some extremely powerful web apps that went far beyond the capabilities of Java Script and used better persistence patterns and stood a much better chance of being cross browser compatible. This is defiantly worth investigating.
"Java IS compiled to native instructions, and has been for about 7 years!"
You understand what the original poster is saying of course. Java is compiled to bytecode. The bytecode is only compiled to native instructions at runtime. This will always be a significant performance hit. gcj rules of course, but nobody uses it yet.
Nonsense. This shows a fundamental misunderstanding of how Hotspot works. Compilation to native code is done in the background. There is no performance hit, which is why Java can now be used successfully for things like real-time control.
Note, in particular, "EBay uses Sun Enterprise Servers in tightly integrated clusters..." Ebay does run Java on big iron.
You need to update your facts. That was from years ago. EBay has been migrating off of such so-called 'big iron' to Linux.
"Right. So no-one is ever going to be allowed to add features to Java because you are insisting that 'write once run anywhere' means that you want to only have, say Java 1.1.8 installed?"
Yes, absolutely. Write once, run ANYWHERE. That's what "anywhere" means.
No it absolutely is not. This has to be the silliest definition I have ever heard.
I'll put it another way. How many times have you had to upgrade your PC physical machine because a new version of GCC came out? Since 1987, maybe twice.
That is a very poor analogy. The appropriate question is 'how many times have you had to upgrade your libc to run newer software since Linux was released'. The answer is many times. Does that mean that Linux is not a portable platform? Of course not! It just means that the libraries get updated on all platforms.
Yet today I'm forced to download two separate virtual machines (1.3.1, and 1.4.2) to install the full Oracle suite. Even you must admit that this indicates a pretty serious problem.
Of course it isn't serious - and exaggerating for effect like this does not help your point. Just because Oracle embed different versions of Java does not mean that other companies don't write very successful portable Java apps. A good example is NetBeans which not only runs on a range of platforms, it even runs on VMs which aren't Sun's (like IBMs) and VMs that aren't even based on Sun's code (HPs). This is as it should be.
That's an even stranger statement! Are you really claiming that, of all programmers in the world, 1 in 3 actively use Java?? That's simply wrong. You'll have to back that assertion up.
It is not simply wrong - it is a simple fact. It is backed by the job market, surveys of developers, surveys of managers, book sales, the TIOBE index, download statistics for development tools.
You may not like it, but the development world today for most people is a Java world.
I'd be very surprised if Google Maps hadn't had hundreds of thousands of users ranging from nerds with Firefox to the elderly.
I'm sure they do, but this is yet again missing the point. There are hundreds of thousands of users who can't use Google Maps because of their browsers.
A site with AJAX can be constructed in a manner that is backwards compatible, too. The AJAX helpers in Ruby on Rails, for example, make it straightforward.
No it can't. There are significant JavaScript compatibility problems with older browsers that made JavaScript development for these a problem. The way that they handled the DOM was quote different, and support for XMLHttpRequest wasn't there.
And don't get me started on the mess that is Ruby on Rails.
Depends on how much advantage you can give to the other 95% of users.
No it doesn't. Suppose you are a large company with a long established customer base. You don't install a technology that immediately cuts off features from 5% of your users. It is very bad business practice.
"But if you are writing a website that has to support hundreds of thousands of users and your customer base ranges from young nerds with the latest Firefox to late-middle aged"
And Google doesn't qualify for that market... how, exactly?
We aren't talking about Google. We are talking about Google Maps. Big difference.
From that, AJAX is supported by 90-95% of their visitors. If you have stats that say otherwise, by all means present them.
Visitors is not the same as users, as a minority of people make up the majority of internet use. You have to consider your target audience. here may be a lot of users out there who occasionally use the internet, and have legacy browsers (I know this to be the case, because if I don't allow backward compatibility, I get a lot of complaints!).
Even if you only reject say 5% of users, you are putting off a large number of potential customers. That is bad news for many business sites.
For companies, this means swap everything over to StarOffice, (possibly) retrain their staff
I have never understood this retraining issue. I have swapped offices over from MS Office to Open Office with very little re-training. There may be some exceptions (such as Mail Merge) but most users are now power users, and don't use complex features. They can recognise simple formatting controls and they can open, save and print documents.
Essentially, if Google, 37signals, etc. are fine with requiring a modern browser, so am I.
Fine. Good luck to you. But if you are writing a website that has to support hundreds of thousands of users and your customer base ranges from young nerds with the latest Firefox to late-middle aged who are still using IE4/5 on Win98, then modern AJAX (as against lots of old JavaScript hacks) just won't do the job.
This is why I responded in the negative to the statement that AJAX is OK for 90% of users. It isn't. Really.
That you and I in reality agree on most things (with the exception that you like java and I don't):-)
True.
I was just a wee bit too harsh in the first message and we got a bit carried away (oh, and don't mix up memes: it's "BSD is dead", and "Java is slow"!).
I don't think I got carried away. I was trying (and obviously failing) to describe what applets can do now, as against what people have been doing with applets for the best part of 10 years.
You have forgotten "Sun is doomed" and "Microsoft is evil" (well, the last one is true actually)
See the object of this thread? It's "java applets".
Why do you keep listing full fledged applications?
Because poster keep mentioning Java rather than 'Java applets', with such statements as 'Java is dead' or 'Java is slow'. I am replying to what is actually posted, rather that what posters think they are posting. However, there seems to be such misunderstanding here that I would not be surprised if many posters actually believe that Java is only applets!
I assume you share my opinion on semi useless and ugly applets, then;-P
That is too simple:)
I believe that a large number of applets are definitely semi-useless and ugly, but that is not my point. I believe that applets can be highly useful and attractive, especially now that developers aren't relying on the ugly and outdated Microsoft JVM that was bundled with Windows for years, and which resulted in most of the problems. Now that companies like Dell and Apple are bundling up-to-date JVMs, Applets can start to be a very useful technology again. They don't need to be restricted to fixed-size grey squares. They can use some very beautiful and innovative Swing-based GUIs. They can use the huge hotspot-based performance improvements in Java 1.4 and 5.0.
I think AJAX is really useful, but it just won't cut it for really high response situations - games for example, or real-time reports. Or serious graphics. Applets can now handle this kind of thing. That is what I use them for.
You give a mathematical/logical proof that fast java apps exist. I'm fine with that.
I didn't give a mathematical proof of fast Java apps. It is simple experience. I'll give you one extreme example that is quite fun - Java is getting widely used in the aerospace industry for real-time control because it is both fast and very safe and secure. Boeing now have a remote-controlled & robotic plane that has it's software written in Java. Also, one of the competitors in this year's DARPA robot vehicle race - Tommy - has software written in Java. So, this is fast, real-time AI and control software - in Java. So, you may not think that Java is fast, but Boeing does! I believe them.
I say that the simple fact that you have to struggle to find 2-3 apps worth mentioning gives me practical proof that they are RARE, thus proving my point.
I struggled to find 2-3 applets worth mentioning. Quality Java GUI applications are numerous. Apart from Eclipse, NetBeans and Intelli/J (used by hundreds of thousands of developers), I'll mention a few others:
the oXygen XML/XSLT editor/processor (I use it pretty often). Jake2 is a Java version of Quake2. Fast, 3D. Blue - music composition system for Csounds synth - multimedia, real-time. Raja - a high-performance 3D rendering system. Cabochon - a MUD RPG that uses Swing (and also uses embedded Jython)
There are thousands of boring Swing apps out there - system monitoring, reporting, database quering etc, but I picked some which were fun and showed specifically that Java can be used for high performance stuff.
Besides, directx or opengl acceleration means close to nothing to the percieved speed of an application. If your app does OpenGL visualization then good. But 99% of the apps dont.
On windows Java apps use directx/opengl by default, so your 99% is false. And they do have a direct effect on the speed, as this API is used for almost all aspects of the GUI display - bitmaps, line drawing, filling etc.
On the subject of SWING looks: if I understand correctly only Java5 apps _correctly coded_ obey to the SWING LAFs
I don't understand what you mean by this.
the gtk LAF is still very buggy
True.
and the others are just skins.
I don't understand what you mean by this. The Windows Swing UI is not a skin. The MacOS/X UI is not a skin (and is so close the the native UI that most people never notice).
A skin does not give you look an feel. Just look
True, but the feel of any Swing APP is fully tunable, by subclassing the standard controls.
"You can't assume browsers have turned on JavaScript either"
It's a safer assumption.
Not really. A good developer should assume that neither Java or JavaScript are present.
"AJAX takes off because it can reach over 90% of users, and especially the mainstream ones."
"It doesn't. It reaches only the users with browsers which support the latest JavaScript."
Which probably is somewhere near, oh, 90% of users.
I think you should do a bit of research before posting. Try Google Maps on even moderately old browsers and you will see it complain. Here is the compatibility note:
"Google Maps is not compatible with every web browser. Google Maps currently supports recent versions of Firefox/Mozilla, IE 5.5+, Safari 1.2+, and sort of supports Opera. IE 5.0 is not supported"
If you had experience of writing a large commercial website you would realise that that does not mean 90% of all users - not even somewhere near!
However, suppose it was 90%, or even 95%.... on a large website with thousands of users per day, that means you are rejecting a substantial number of people.
I like the idea of AJAX for many purposes - it seems particularly good for internal company use where you can guarantee browser versions, or for stuff like 'google maps' which is a fun or convenience thing. However, anyone who uses it for essential stuff on sites where you can't guarantee the browser type is going to make a lot of users very annoyed.
Yes just displaced that title from COBOL congratulations, but real software isnt developed in languages used by IT, not operating systems, not webservers, not rdbms, not compilers, not even webbrowsers nothing important in the grand scheme of things
There is a high-performance Java webserver - tomcat 5.5 does this and even matches Apache in some benchmarks.
There is a high-performance Java database - HSQLDB.
And, of course, the Java compiler itself is written in Java.
There are also real-time high-performance device control systems, games, mobile devices, interpreters for other languages - you name it, it has been written in Java.
I will use an IDE compiled to native instructions that dosent grind my machine to a halt, thank you very much.
I really don't understand how such a lack of knowledge of Java persists on these forums. Java IS compiled to native instructions, and has been for about 7 years!
This oft repeated misnomer is tiresome, wow java preforms well on servers that cost north of 40k thats great, If I hade serveral GB of RAM and multiple processors maybe I too wouldnt notice a difference between java and native compiled code, oh wait I do, and the performance of java is still blows.
Perhaps you should actually take a look at the e-Bay infrastructure before you comment? Those specs are, of course, nonsense.
Java is irrelevant too real programmers, a terrible "platform" in its own right, and even worse language but I dont fell like ranting about that right this instant.
A strange statement, as about three quarters of 'real' programmers use Java. Unless you are simply labelling anyone who uses Java as not a real programmer.
Write once run anywhere in the context of java is utter and complete bullshit otherwise I wouldnt need to have two versions of the jdk installed on my machine....
Right. So no-one is ever going to be allowed to add features to Java because you are insisting that 'write once run anywhere' means that you want to only have, say Java 1.1.8 installed?
I hope you didn't invest much time learning Java because it is going the way of the cuckoo.
Java is the most successful and widely used language in IT, and it's use is growing. You are confusing applets with Server side Java throughout your post. Saying 'Java is going the way of the cuckoo' is as dumb as saying 'the pentium is doomed' or 'no-one uses Windows'. (Actually, cuckoos are doing rather well - perhaps you meant Dodo?)
Java on the client side sucks - everyone knows it.
No. Just because you think that does not mean 'everyone knows it'. One of the most popular IDEs ever produced - Eclipse - is a client side Java app. Do you hear developers saying 'Eclipse sucks'? Of course not.
Thats why no one deploys Java client applications anymore.
Nonsense. You may be interested to know how widely used Java Web Start is - the answer is 'very widely'. Java Web Start is a technology for deploying client side apps.
Why didn't Google choose Java for maps.google.com?
Because they need a distributed API that doesn't need a download. Google use huge amounts of Java for other things on their servers.
Why didnt Microsoft for Virtual Earth?
Because Microsoft dropped use of cross-platform Java years ago!
Why didn't any major web app choose Java?
Most of them DO use Java, but on the server side. For example, e-bay runs almost entirely on Java.
Answer:
- Crappy non-native look and feel
What non-native look and feel? Most applets use the native GUI!
- Slow start up (freezes the browser while Java initializes) and GUI responsiveness
When does this happen? Modern VMs can start up in a fraction of a second. What lack of responsiveness - it uses the native GUI!
- Large downloads required for computers that don't the right version of Java
Wrong. A moderate once-only download (not downloads).
Funny how Slashdotters are so keen for users to download tens of megabytes in order to switch browsers objects so strongly to a much smaller download to keep the JVM up to date!
Is there something about the word 'Java' that blocks intelligent thought processes? Why do I see so many posts which talk about Java as it was nearly a decade ago? I thought nerds were supposed to be up-to-date with IT developments.
Wow, Decaff, you're really working overtime to tell us what is theoretically possible with Java applets.
I'm not working overtime - it is easy:)
Tell you what... How about you give a URL to *one* non-trivial applet that embodies everything you're talking about. Something like Google Maps, Flickr, etc.
Actually, I can't! Just because this is possible, doesn't mean that most people do it, and I admit this. A good applet is like a good Visual Basic program - hard to find! However, I'm going on about this because things should be better than AJAX. GUIs should not be a matter of hacking about with JavaScript. GUIs should not be sending a high volume of messages back and forth over the internet. GUIs should be able to handle megabytes of information in fractions of a second (the idea of a serious large spreadsheet in AJAX is bizarre!)
I do have to comment on one of your requirements, which I think is inappropriate:
It must not care what JVM it's running on. Write once run anywhere, you know. Don't force me to endure a 25 MB download just to run your Java applet.
Why on earth should I write an applet that runs on Java 1.1.8, when Java 5.0 is available? That download (which is NOT 25MB!) will allow you to run any applet, not just mine.
I put a question back to you: "Show me an AJAX page that will run on ANY browser, not just modern ones. I should not have to download tens of megabytes of browser just to run your JavaScript". Get my point?
The problem with Java applets is they require too much to be installed on the client side. This has big security and performance implications, leaving aside the quality of the available JVMs
These days, even an install of a few tens of Megabytes is insignificant. As for security, that has almost never been an issue with applets. Regarding performance implications - what are they? Modern JVMs are fast. The JVMs available these days that you will need to provide applet capabilities on most platforms are the latest from Sun and Apple. These are Java 5.0 and are fast, secure and robust, so what is the quality issue?
I notice you bypassed the remark on SWT. SWT is not java. SWT is native GTK. And is slow and heavy. And I don't think you can use it in applet, do you?
SWT IS Java, in precisely the same way that AWT is Java. There is no difference - they are just alternatives. Most applets use AWT which is native, so you are criticising the native GUI! You can use SWT in signed applets.
The only widely deployed client java gui apps are either for java programmers or in SWT, or both (e.g. NetBeans, Eclipse, Azureus).
This isn't true. There are many widely used Java apps, and far more which use Swing than SWT. One example from last year was the mars rover data viewer which huge numbers of people downloaded from NASA.
Your example of chemical visualization applet sounds neat, for example, in its niche of application. I'm not implying that it's not at all _possible_ do make a fast and useful applet. It's just not done:-)
It is done, because that example shows that it is done!
So applets can use AWT (horrendously limited) or Swing (slow on windows and osx, slow and butt-ugly on linux)... that's not really "wow", is it?
This is simply wrong. Swing is not slow on Windows, OS/X or Linux! It is OpenGL and DirectX accelerated on the appropriate platforms. You may *think* it is slow, based on an old-fashioned experience from years ago, but that is now a minority view.
As for Swing being 'butt-ugly' - there is no single Swing look or feel to call 'butt-ugly'. There are hundreds; so if you don't like the look and feel then change it!
Browser based AJAX jabber client. It works, it's fast, and light. I'd never consider the possibility to use the applets again.
AJAX has advantages, but it is only a front end, and is certainly not fast or flexible for things like that molecule viewer.
I reiterate: can you point me to 2-3 applets available on the web that you consider valuable, useful and maybe even cool?
No. I can't point to 2 or 3 AJAX sites that are cool either - I only use 1 (Google maps) and only for fun occasionally. I have found applets to be a valuable way to provide fast GUIs on intranets.
On my workstation (P4 with 512MB RAM) opening a page with applets results in several seconds of system slowdown (not mentioning browser freeze). If you ONLY use a browser and nothing else your figures may be sensible.
No. My figures are for a loaded machine.
"Applets were slow about 7-8 years ago. Now there are high-performance JIT and Hotspot VMs."
You seem to live in a dreamworld. I have yet to se a fast applet, let alone a useful one.
If it is a dreamworld, it is one in which I make money as a Java developer! Just because you have yet to see what you believe is a fast applet, does not mean there aren't any. Applets are quite often used internally within companies to provide information. One example of a fast applet I have seen is a molecular display system used for teaching. Speed is important (it needs to render 3D pictures).
This seems to confirm that you are either a java zealot, a troll, or live in the aforementioned dreamworld. Java GUIs on windows are ugly but manageable. Java GUIs on linux look nothing like anything they are trying to emulate. And note that I also mentioned feel. Java apps NEVER feel like native ones (or maybe you are implying that all java developers are getting it wrong... which could well be:-) )
There are two types of GUI that are are used with applets. (1) The actual native GUI of the system. (2) Swing (which on systems like MacOS/X is coded by Apple to match the native GUI very closely indeed).
To say that Java GUIs on Windows are ugly is to say that Windows is ugly, as the majority of applet GUIs on windows actually use Windows. To say (in the context of applets) that Java apps NEVER feel like native apps is simply nonsense, as this is to say that the Windows GUI never feels like the Windows GUI! Apple have put a lot of work in to ensure that even general Java apps on MacOS/X look exactly like native Mac apps. To say that Java apps on Linux 'never look like anything they are trying to emulate' is not only wrong, it is factually incorrect, as the most popular Java app on Linux - Eclipse does not emulate anything! It uses standard GUI libraries like Motif and GTK.
"Java is pre-installed on more than half of all new PCs. If not, it is a once-only install that does not take that long on broadband..."
Dunno where you live. Where I live, java is almost NEVER preinstalled. Broadband is not really broadly deployed, and a lot of users could well be incapable of installing a JVM.
Again, you are extrapolating your personal experience as if it was general. In the UK, for example broadband IS broadly deployed. As for installing a JVM, this is a single click!
I'm not really trying to flame you or java or whatever...
The 'you live in a dreamworld' statements suggest the opposite.
the fact is simply that I never stumbled on a useful java applet EVER. Quite the opposite: I've seen to many horrible and completely useless applets in these years. Just let java live on the server side (if anywhere), and put applets to rest, please.
Why should developers stop using applets (which can provide very fast browser-based GUIs for many purposes) stop using applets just because you have never 'stumbled' on a useful Java applet?
For one the fact that the starting VM can bring down to a halt even a semi-fast machine.
On my workstation a VM starts in less than a second and uses only a fraction of memory by default. I fail to see how this can 'bring down' a machine.
Or the fact that applets are SLOW, whereas (for example) gmail and googlemaps are FAST.
Applets were slow about 7-8 years ago. Now there are high-performance JIT and Hotspot VMs.
I don't find googlemaps fast! An applet that caches data locally can be pretty much as fast as you like.
Or maybe it's that java guis just plain suck in pretty much every aspect (look, feel, functionality, ergonomy).
This is a strange comment, as Java GUIs are totally customisable and 'skinnable' by developers. So, you are declaring that every aspect of several hundred different GUIs suck! Many Applets use the native GUI of the OS, so you are also saying that Windows, MacOS/X, KDE, GNOME etc. also suck!
Oh, and the fact that java is not installed on machines anymore (by default), whereas a browser is (even if maybe a louse one as IE6).
Java is pre-installed on more than half of all new PCs. If not, it is a once-only install that does not take that long on broadband....
Seems like you are talking about applets as they were nearly a decade ago.
However it sounded (to me) like what were saying is 'All we need to do is keep them warm and dark' in which case, the number of failures listed would point towards it's being more complicated (or the previous attempters being really dumb)
I was not saying that. What I was objecting to was one of the original posters saying that the significant pressure differences would naturally and obviously result in major chemical/biochemical problems for animals if they were bought up to the surface. This is nonsense. Pressure alone (particularly in a liquid medium) has extremely minor effects on biochemistry. A few animals may have very specific adaptations to pressure in the form of highly tailored enzymes, but these are going to be the exceptions as it will limit where they can live.
What really matters for animals living at depth is not pressure at all - it is (1) temperature. It is cold at the bottom of the oceans, and the temperature doesn't change much. (2) Oxygen concentrations are low. (3) Food is sparse.
I haven't said it isn't complicated to keep animals from the depths alive in aquaria. It is complicated to keep almost any wild oceanic creatures alive in these conditions. My point is that the problem is almost never a matter of pressure.
I guess my real complaint is when common science programs invariably say that creatures that live at depth 'are very strong because they have to survive under such pressures' as if deep-see jellyfish are supposed to be built like bathyscapes...
Well according to this http://news.nationalgeographic.com/news/2004/07/07 01_040701_oceantrap.html many deep sea fish die simply in the process of being captured and transported to the surface due to changes in "temperature and pressure"
Of course! In such cases the changes in pressure and temperature can be rapid, which would naturally be damaging to most organisms. There can also be excessive oxygen present, which can also be fatal.
One example of a high-pressure-adapted enzyme does not contradict my point.
And according to this http://en.wikipedia.org/wiki/Deep_sea_fish "These fish live at depths of several kilometres with pressures of several hundred atmospheres; as a result they cannot survive at sea level and any attempts to keep them in captivity has led to their death."
This is not a valid statement. Living at pressures of several hundred atmospheres does not of itself imply that that such organisms can't survive at sea level. This is obviously false as there are many animals that normally migrate between such pressure ranges!
So raising them in captivity is probably a bit more complicated than simply turning down the lights and attaching a small refrigeration unit.
There are very, very many reasons why wild animals die in capitivity, and they can be very complex. For example, the animals may starve as a result of the lack of chemical cues in the water. Some deep-sea squid species will grow to a certain age in captivity but then stop eating because some (as yet) unknown factor is present.
Slashdot Mirror
If you only write a spec, then implement, then change the spec and reimplement again in short cycles, then the spec can serve nothing more as a description one abstraction level higher than the actual code itself, instead of being a planning device with long-term stability.
I'm not sure what is wrong with that. A spec should settle down into something stable in the long term.
This seems to be the case in most western populations. Life expectancy isn't going up because people are starting to 120, it's going up because infant mortality is coming down.
This simply isn't true. There have been advances in the understanding of heath and the affect of lifestyle on longevity. Fewer people smoke, we generally eat a better diet and we have effective treatments for systemic conditions such as high blood pressure. This means that fewer people are dying in their 50s and 60s of heart disease and cancer.
The proof of increased lifespan (and not just lack of infant mortality) is the potential crisis in pensions in the western world. People were expected to live only 5-10 years after retirement. People now routinely live 20-25 years and some even 30 or more.
Specs are not best for software whose features are to grow with time
Why not? Specs can change and grow with time as well.
I was amazed to hear that there is an Applet API for DOM interaction. Is there any work to make this cross browser compatible?
It already is! There was an API that was introduced for Netscape, but it was extended by Sun to allow JavaScript and DOM interaction for all modern browsers (although there are some differences). It is called LiveConnect, and provides netscape.* packages for applets.
Java Applet technology has changed beyond recognition in the past few years - I find the idea of Java Applet interaction with JavaScript and AJAX to be very exciting and powerful.
I can see how something like this could make an excellent "Web 2.0" ish version that didn't rely on redoing every page in Java Script (thus creating a nightmare of code to support) It seems like you could build some extremely powerful web apps that went far beyond the capabilities of Java Script and used better persistence patterns and stood a much better chance of being cross browser compatible. This is defiantly worth investigating.
My view exactly!
"Java IS compiled to native instructions, and has been for about 7 years!"
. htm
You understand what the original poster is saying of course. Java is compiled to bytecode. The bytecode is only compiled to native instructions at runtime. This will always be a significant performance hit. gcj rules of course, but nobody uses it yet.
Nonsense. This shows a fundamental misunderstanding of how Hotspot works. Compilation to native code is done in the background. There is no performance hit, which is why Java can now be used successfully for things like real-time control.
You're wrong.
http://www.internetweek.com/newslead01/lead011101
Note, in particular, "EBay uses Sun Enterprise Servers in tightly integrated clusters..." Ebay does run Java on big iron.
You need to update your facts. That was from years ago. EBay has been migrating off of such so-called 'big iron' to Linux.
"Right. So no-one is ever going to be allowed to add features to Java because you are insisting that 'write once run anywhere' means that you want to only have, say Java 1.1.8 installed?"
Yes, absolutely. Write once, run ANYWHERE. That's what "anywhere" means.
No it absolutely is not. This has to be the silliest definition I have ever heard.
I'll put it another way. How many times have you had to upgrade your PC physical machine because a new version of GCC came out? Since 1987, maybe twice.
That is a very poor analogy. The appropriate question is 'how many times have you had to upgrade your libc to run newer software since Linux was released'. The answer is many times. Does that mean that Linux is not a portable platform? Of course not! It just means that the libraries get updated on all platforms.
Yet today I'm forced to download two separate virtual machines (1.3.1, and 1.4.2) to install the full Oracle suite. Even you must admit that this indicates a pretty serious problem.
Of course it isn't serious - and exaggerating for effect like this does not help your point. Just because Oracle embed different versions of Java does not mean that other companies don't write very successful portable Java apps. A good example is NetBeans which not only runs on a range of platforms, it even runs on VMs which aren't Sun's (like IBMs) and VMs that aren't even based on Sun's code (HPs). This is as it should be.
That's an even stranger statement! Are you really claiming that, of all programmers in the world, 1 in 3 actively use Java?? That's simply wrong. You'll have to back that assertion up.
It is not simply wrong - it is a simple fact. It is backed by the job market, surveys of developers, surveys of managers, book sales, the TIOBE index, download statistics for development tools.
You may not like it, but the development world today for most people is a Java world.
I'd be very surprised if Google Maps hadn't had hundreds of thousands of users ranging from nerds with Firefox to the elderly.
I'm sure they do, but this is yet again missing the point. There are hundreds of thousands of users who can't use Google Maps because of their browsers.
A site with AJAX can be constructed in a manner that is backwards compatible, too. The AJAX helpers in Ruby on Rails, for example, make it straightforward.
No it can't. There are significant JavaScript compatibility problems with older browsers that made JavaScript development for these a problem. The way that they handled the DOM was quote different, and support for XMLHttpRequest wasn't there.
And don't get me started on the mess that is Ruby on Rails.
Depends on how much advantage you can give to the other 95% of users.
No it doesn't. Suppose you are a large company with a long established customer base. You don't install a technology that immediately cuts off features from 5% of your users. It is very bad business practice.
"But if you are writing a website that has to support hundreds of thousands of users and your customer base ranges from young nerds with the latest Firefox to late-middle aged"
And Google doesn't qualify for that market... how, exactly?
We aren't talking about Google. We are talking about Google Maps. Big difference.
From that, AJAX is supported by 90-95% of their visitors. If you have stats that say
otherwise, by all means present them.
Visitors is not the same as users, as a minority of people make up the majority of internet use. You have to consider your target audience. here may be a lot of users out there who occasionally use the internet, and have legacy browsers (I know this to be the case, because if I don't allow backward compatibility, I get a lot of complaints!).
Even if you only reject say 5% of users, you are putting off a large number of potential customers. That is bad news for many business sites.
For companies, this means swap everything over to StarOffice, (possibly) retrain their staff
I have never understood this retraining issue. I have swapped offices over from MS Office to Open Office with very little re-training. There may be some exceptions (such as Mail Merge) but most users are now power users, and don't use complex features. They can recognise simple formatting controls and they can open, save and print documents.
Essentially, if Google, 37signals, etc. are fine with requiring a modern browser, so am I.
Fine. Good luck to you. But if you are writing a website that has to support hundreds of thousands of users and your customer base ranges from young nerds with the latest Firefox to late-middle aged who are still using IE4/5 on Win98, then modern AJAX (as against lots of old JavaScript hacks) just won't do the job.
This is why I responded in the negative to the statement that AJAX is OK for 90% of users. It isn't. Really.
You know what's really funny?
:-)
That you and I in reality agree on most things (with the exception that you like java and I don't)
True.
I was just a wee bit too harsh in the first message and we got a bit carried away (oh, and don't mix up memes: it's "BSD is dead", and "Java is slow"!).
I don't think I got carried away. I was trying (and obviously failing) to describe what applets can do now, as against what people have been doing with applets for the best part of 10 years.
You have forgotten "Sun is doomed" and "Microsoft is evil" (well, the last one is true actually)
See the object of this thread? It's "java applets".
;-P
:)
Why do you keep listing full fledged applications?
Because poster keep mentioning Java rather than 'Java applets', with such statements as 'Java is dead' or 'Java is slow'. I am replying to what is actually posted, rather that what posters think they are posting. However, there seems to be such misunderstanding here that I would not be surprised if many posters actually believe that Java is only applets!
I assume you share my opinion on semi useless and ugly applets, then
That is too simple
I believe that a large number of applets are definitely semi-useless and ugly, but that is not my point. I believe that applets can be highly useful and attractive, especially now that developers aren't relying on the ugly and outdated Microsoft JVM that was bundled with Windows for years, and which resulted in most of the problems. Now that companies like Dell and Apple are bundling up-to-date JVMs, Applets can start to be a very useful technology again. They don't need to be restricted to fixed-size grey squares. They can use some very beautiful and innovative Swing-based GUIs. They can use the huge hotspot-based performance improvements in Java 1.4 and 5.0.
I think AJAX is really useful, but it just won't cut it for really high response situations - games for example, or real-time reports. Or serious graphics. Applets can now handle this kind of thing. That is what I use them for.
You give a mathematical/logical proof that fast java apps exist. I'm fine with that.
I didn't give a mathematical proof of fast Java apps. It is simple experience. I'll give you one extreme example that is quite fun - Java is getting widely used in the aerospace industry for real-time control because it is both fast and very safe and secure. Boeing now have a remote-controlled & robotic plane that has it's software written in Java. Also, one of the competitors in this year's DARPA robot vehicle race - Tommy - has software written in Java. So, this is fast, real-time AI and control software - in Java. So, you may not think that Java is fast, but Boeing does! I believe them.
I say that the simple fact that you have to struggle to find 2-3 apps worth mentioning gives me practical proof that they are RARE, thus proving my point.
I struggled to find 2-3 applets worth mentioning. Quality Java GUI applications are numerous. Apart from Eclipse, NetBeans and Intelli/J (used by hundreds of thousands of developers), I'll mention a few others:
the oXygen XML/XSLT editor/processor (I use it pretty often).
Jake2 is a Java version of Quake2. Fast, 3D.
Blue - music composition system for Csounds synth - multimedia, real-time.
Raja - a high-performance 3D rendering system.
Cabochon - a MUD RPG that uses Swing (and also uses embedded Jython)
There are thousands of boring Swing apps out there - system monitoring, reporting, database quering etc, but I picked some which were fun and showed specifically that Java can be used for high performance stuff.
Besides, directx or opengl acceleration means close to nothing to the percieved speed of an application. If your app does OpenGL visualization then good. But 99% of the apps dont.
On windows Java apps use directx/opengl by default, so your 99% is false. And they do have a direct effect on the speed, as this API is used for almost all aspects of the GUI display - bitmaps, line drawing, filling etc.
On the subject of SWING looks: if I understand correctly only Java5 apps _correctly coded_ obey to the SWING LAFs
I don't understand what you mean by this.
the gtk LAF is still very buggy
True.
and the others are just skins.
I don't understand what you mean by this. The Windows Swing UI is not a skin. The MacOS/X UI is not a skin (and is so close the the native UI that most people never notice).
A skin does not give you look an feel. Just look
True, but the feel of any Swing APP is fully tunable, by subclassing the standard controls.
"You can't assume browsers have turned on JavaScript either"
It's a safer assumption.
Not really. A good developer should assume that neither Java or JavaScript are present.
"AJAX takes off because it can reach over 90% of users, and especially the mainstream ones."
"It doesn't. It reaches only the users with browsers which support the latest JavaScript."
Which probably is somewhere near, oh, 90% of users.
I think you should do a bit of research before posting. Try Google Maps on even moderately old browsers and you will see it complain. Here is the compatibility note:
"Google Maps is not compatible with every web browser. Google Maps currently supports recent versions of Firefox/Mozilla, IE 5.5+, Safari 1.2+, and sort of supports Opera. IE 5.0 is not supported"
If you had experience of writing a large commercial website you would realise that that does not mean 90% of all users - not even somewhere near!
However, suppose it was 90%, or even 95%.... on a large website with thousands of users per day, that means you are rejecting a substantial number of people.
I like the idea of AJAX for many purposes - it seems particularly good for internal company use where you can guarantee browser versions, or for stuff like 'google maps' which is a fun or convenience thing. However, anyone who uses it for essential stuff on sites where you can't guarantee the browser type is going to make a lot of users very annoyed.
Yes just displaced that title from COBOL congratulations, but real software isnt developed in languages used by IT, not operating systems, not webservers, not rdbms, not compilers, not even webbrowsers nothing important in the grand scheme of things
There is a high-performance Java webserver - tomcat 5.5 does this and even matches Apache in some benchmarks.
There is a high-performance Java database - HSQLDB.
And, of course, the Java compiler itself is written in Java.
There are also real-time high-performance device control systems, games, mobile devices, interpreters for other languages - you name it, it has been written in Java.
I will use an IDE compiled to native instructions that dosent grind my machine to a halt, thank you very much.
I really don't understand how such a lack of knowledge of Java persists on these forums. Java IS compiled to native instructions, and has been for about 7 years!
This oft repeated misnomer is tiresome, wow java preforms well on servers that cost north of 40k thats great, If I hade serveral GB of RAM and multiple processors maybe I too wouldnt notice a difference between java and native compiled code, oh wait I do, and the performance of java is still blows.
Perhaps you should actually take a look at the e-Bay infrastructure before you comment? Those specs are, of course, nonsense.
Java is irrelevant too real programmers, a terrible "platform" in its own right, and even worse language but I dont fell like ranting about that right this instant.
A strange statement, as about three quarters of 'real' programmers use Java. Unless you are simply labelling anyone who uses Java as not a real programmer.
Write once run anywhere in the context of java is utter and complete bullshit otherwise I wouldnt need to have two versions of the jdk installed on my machine....
Right. So no-one is ever going to be allowed to add features to Java because you are insisting that 'write once run anywhere' means that you want to only have, say Java 1.1.8 installed?
Sun killed Java through stupidity.
Strange definition of 'killed', as Java is the most widely used development language.
I hope you didn't invest much time learning Java because it is going the way of the cuckoo.
Java is the most successful and widely used language in IT, and it's use is growing. You are confusing applets with Server side Java throughout your post. Saying 'Java is going the way of the cuckoo' is as dumb as saying 'the pentium is doomed' or 'no-one uses Windows'. (Actually, cuckoos are doing rather well - perhaps you meant Dodo?)
Java on the client side sucks - everyone knows it.
No. Just because you think that does not mean 'everyone knows it'. One of the most popular IDEs ever produced - Eclipse - is a client side Java app. Do you hear developers saying 'Eclipse sucks'? Of course not.
Thats why no one deploys Java client applications anymore.
Nonsense. You may be interested to know how widely used Java Web Start is - the answer is 'very widely'. Java Web Start is a technology for deploying client side apps.
Why didn't Google choose Java for maps.google.com?
Because they need a distributed API that doesn't need a download. Google use huge amounts of Java for other things on their servers.
Why didnt Microsoft for Virtual Earth?
Because Microsoft dropped use of cross-platform Java years ago!
Why didn't any major web app choose Java?
Most of them DO use Java, but on the server side.
For example, e-bay runs almost entirely on Java.
Answer:
- Crappy non-native look and feel
What non-native look and feel? Most applets use the native GUI!
- Slow start up (freezes the browser while Java initializes) and GUI responsiveness
When does this happen? Modern VMs can start up in a fraction of a second. What lack of responsiveness - it uses the native GUI!
- Large downloads required for computers that don't the right version of Java
Wrong. A moderate once-only download (not downloads).
Funny how Slashdotters are so keen for users to download tens of megabytes in order to switch browsers objects so strongly to a much smaller download to keep the JVM up to date!
Is there something about the word 'Java' that blocks intelligent thought processes? Why do I see so many posts which talk about Java as it was nearly a decade ago? I thought nerds were supposed to be up-to-date with IT developments.
Is it possible to make Java applets take up the entire size of the browser window?
Yes. You can do this with a combination of JavaScript and the LiveConnect API.
Wow, Decaff, you're really working overtime to tell us what is theoretically possible with Java applets.
:)
I'm not working overtime - it is easy
Tell you what... How about you give a URL to *one* non-trivial applet that embodies everything you're talking about. Something like Google Maps, Flickr, etc.
Actually, I can't! Just because this is possible, doesn't mean that most people do it, and I admit this. A good applet is like a good Visual Basic program - hard to find! However, I'm going on about this because things should be better than AJAX. GUIs should not be a matter of hacking about with JavaScript. GUIs should not be sending a high volume of messages back and forth over the internet. GUIs should be able to handle megabytes of information in fractions of a second (the idea of a serious large spreadsheet in AJAX is bizarre!)
I do have to comment on one of your requirements, which I think is inappropriate:
It must not care what JVM it's running on. Write once run anywhere, you know. Don't force me to endure a 25 MB download just to run your Java applet.
Why on earth should I write an applet that runs on Java 1.1.8, when Java 5.0 is available? That download (which is NOT 25MB!) will allow you to run any applet, not just mine.
I put a question back to you: "Show me an AJAX page that will run on ANY browser, not just modern ones. I should not have to download tens of megabytes of browser just to run your JavaScript". Get my point?
The problem with Java applets is they require too much to be installed on the client side. This has big security and performance implications, leaving aside the quality of the available JVMs
These days, even an install of a few tens of Megabytes is insignificant. As for security, that has almost never been an issue with applets. Regarding performance implications - what are they? Modern JVMs are fast. The JVMs available these days that you will need to provide applet capabilities on most platforms are the latest from Sun and Apple. These are Java 5.0 and are fast, secure and robust, so what is the quality issue?
I notice you bypassed the remark on SWT. SWT is not java. SWT is native GTK. And is slow and heavy. And I don't think you can use it in applet, do you?
:-)
SWT IS Java, in precisely the same way that AWT is Java. There is no difference - they are just alternatives. Most applets use AWT which is native, so you are criticising the native GUI! You can use SWT in signed applets.
The only widely deployed client java gui apps are either for java programmers or in SWT, or both (e.g. NetBeans, Eclipse, Azureus).
This isn't true. There are many widely used Java apps, and far more which use Swing than SWT. One example from last year was the mars rover data viewer which huge numbers of people downloaded from NASA.
Your example of chemical visualization applet sounds neat, for example, in its niche of application. I'm not implying that it's not at all _possible_ do make a fast and useful applet. It's just not done
It is done, because that example shows that it is done!
So applets can use AWT (horrendously limited) or Swing (slow on windows and osx, slow and butt-ugly on linux)... that's not really "wow", is it?
This is simply wrong. Swing is not slow on Windows, OS/X or Linux! It is OpenGL and DirectX accelerated on the appropriate platforms. You may *think* it is slow, based on an old-fashioned experience from years ago, but that is now a minority view.
As for Swing being 'butt-ugly' - there is no single Swing look or feel to call 'butt-ugly'. There are hundreds; so if you don't like the look and feel then change it!
Browser based AJAX jabber client. It works, it's fast, and light. I'd never consider the possibility to use the applets again.
AJAX has advantages, but it is only a front end, and is certainly not fast or flexible for things like that molecule viewer.
I reiterate: can you point me to 2-3 applets available on the web that you consider valuable, useful and maybe even cool?
No. I can't point to 2 or 3 AJAX sites that are cool either - I only use 1 (Google maps) and only for fun occasionally. I have found applets to be a valuable way to provide fast GUIs on intranets.
More reasons applets suck:
- Cannot assume most browsers have it turned on
You can't assume browsers have turned on JavaScript either, so your AJAX solution won't work in that case.
- Full-page UI (i.e. not just in a little rectangle) is harder
No it isn't. You simply open a new window.
- Java loading slow gives trademark 'grey square'
It need not - this is just bad coding and nothing specific to Java.
AJAX takes off because it can reach over 90% of users, and especially the mainstream ones.
It doesn't. It reaches only the users with browsers which support the latest JavaScript.
AJAX allows the full DOM and has an excellent familiar object model for manipulating the DOM (Javascript)
And there are Applet APIs for doing this.
AJAX pages while loading look like a loading web page.
So so applets if well written.
On my workstation (P4 with 512MB RAM) opening a page with applets results in several seconds of system slowdown (not mentioning browser freeze). If you ONLY use a browser and nothing else your figures may be sensible.
:-) )
No. My figures are for a loaded machine.
"Applets were slow about 7-8 years ago. Now there are high-performance JIT and Hotspot VMs."
You seem to live in a dreamworld. I have yet to se a fast applet, let alone a useful one.
If it is a dreamworld, it is one in which I make money as a Java developer! Just because you have yet to see what you believe is a fast applet, does not mean there aren't any. Applets are quite often used internally within companies to provide information. One example of a fast applet I have seen is a molecular display system used for teaching. Speed is important (it needs to render 3D pictures).
This seems to confirm that you are either a java zealot, a troll, or live in the aforementioned dreamworld. Java GUIs on windows are ugly but manageable. Java GUIs on linux look nothing like anything they are trying to emulate. And note that I also mentioned feel. Java apps NEVER feel like native ones (or maybe you are implying that all java developers are getting it wrong... which could well be
There are two types of GUI that are are used with applets. (1) The actual native GUI of the system. (2) Swing (which on systems like MacOS/X is coded by Apple to match the native GUI very closely indeed).
To say that Java GUIs on Windows are ugly is to say that Windows is ugly, as the majority of applet GUIs on windows actually use Windows. To say (in the context of applets) that Java apps NEVER feel like native apps is simply nonsense, as this is to say that the Windows GUI never feels like the Windows GUI! Apple have put a lot of work in to ensure that even general Java apps on MacOS/X look exactly like native Mac apps. To say that Java apps on Linux 'never look like anything they are trying to emulate' is not only wrong, it is factually incorrect, as the most popular Java app on Linux - Eclipse does not emulate anything! It uses standard GUI libraries like Motif and GTK.
"Java is pre-installed on more than half of all new PCs. If not, it is a once-only install that does not take that long on broadband..."
Dunno where you live. Where I live, java is almost NEVER preinstalled. Broadband is not really broadly deployed, and a lot of users could well be incapable of installing a JVM.
Again, you are extrapolating your personal experience as if it was general. In the UK, for example broadband IS broadly deployed. As for installing a JVM, this is a single click!
I'm not really trying to flame you or java or whatever...
The 'you live in a dreamworld' statements suggest the opposite.
the fact is simply that I never stumbled on a useful java applet EVER. Quite the opposite: I've seen to many horrible and completely useless applets in these years. Just let java live on the server side (if anywhere), and put applets to rest, please.
Why should developers stop using applets (which can provide very fast browser-based GUIs for many purposes) stop using applets just because you have never 'stumbled' on a useful Java applet?
For one the fact that the starting VM can bring down to a halt even a semi-fast machine.
On my workstation a VM starts in less than a second and uses only a fraction of memory by default. I fail to see how this can 'bring down' a machine.
Or the fact that applets are SLOW, whereas (for example) gmail and googlemaps are FAST.
Applets were slow about 7-8 years ago. Now there are high-performance JIT and Hotspot VMs.
I don't find googlemaps fast! An applet that caches data locally can be pretty much as fast as you like.
Or maybe it's that java guis just plain suck in pretty much every aspect (look, feel, functionality, ergonomy).
This is a strange comment, as Java GUIs are totally customisable and 'skinnable' by developers. So, you are declaring that every aspect of several hundred different GUIs suck! Many Applets use the native GUI of the OS, so you are also saying that Windows, MacOS/X, KDE, GNOME etc. also suck!
Oh, and the fact that java is not installed on machines anymore (by default), whereas a browser is (even if maybe a louse one as IE6).
Java is pre-installed on more than half of all new PCs. If not, it is a once-only install that does not take that long on broadband....
Seems like you are talking about applets as they were nearly a decade ago.
However it sounded (to me) like what were saying is 'All we need to do is keep them warm and dark' in which case, the number of failures listed would point towards it's being more complicated (or the previous attempters being really dumb)
I was not saying that. What I was objecting to was one of the original posters saying that the significant pressure differences would naturally and obviously result in major chemical/biochemical problems for animals if they were bought up to the surface. This is nonsense. Pressure alone (particularly in a liquid medium) has extremely minor effects on biochemistry. A few animals may have very specific adaptations to pressure in the form of highly tailored enzymes, but these are going to be the exceptions as it will limit where they can live.
What really matters for animals living at depth is not pressure at all - it is (1) temperature. It is cold at the bottom of the oceans, and the temperature doesn't change much. (2) Oxygen concentrations are low. (3) Food is sparse.
I haven't said it isn't complicated to keep animals from the depths alive in aquaria. It is complicated to keep almost any wild oceanic creatures alive in these conditions. My point is that the problem is almost never a matter of pressure.
I guess my real complaint is when common science programs invariably say that creatures that live at depth 'are very strong because they have to survive under such pressures' as if deep-see jellyfish are supposed to be built like bathyscapes...
Well according to this7 01_040701_oceantrap.html
t icle_id=218391869&cat=1_1
http://news.nationalgeographic.com/news/2004/07/0
many deep sea fish die simply in the process of being captured and transported to the surface due to changes in "temperature and pressure"
Of course! In such cases the changes in pressure and temperature can be rapid, which would naturally be damaging to most organisms. There can also be excessive oxygen present, which can also be fatal.
and according to this
http://www.sciencentral.com/articles/view.php3?ar
at least one known fish has an enzyme which simply doesn't work at aquarium pressures (so it dies)
One example of a high-pressure-adapted enzyme does not contradict my point.
And according to this
http://en.wikipedia.org/wiki/Deep_sea_fish
"These fish live at depths of several kilometres with pressures of several hundred atmospheres; as a result they cannot survive at sea level and any attempts to keep them in captivity has led to their death."
This is not a valid statement. Living at pressures of several hundred atmospheres does not of itself imply that that such organisms can't survive at sea level. This is obviously false as there are many animals that normally migrate between such pressure ranges!
So raising them in captivity is probably a bit more complicated than simply turning down the lights and attaching a small refrigeration unit.
There are very, very many reasons why wild animals die in capitivity, and they can be very complex. For example, the animals may starve as a result of the lack of chemical cues in the water. Some deep-sea squid species will grow to a certain age in captivity but then stop eating because some (as yet) unknown factor is present.