And what a shame that would be, all those CPU cycles currently going to the JVM..
what are you talking about? the jvm is just a program like any other. What 'wrapper classes'? if you read recent slashdot articles you should have noticed that java is fast.
JVMs dont magically eat up cpu cycles or memory. Java can run on small embedded systems and mobile phones.
Java is installed on 60-70% of all new PCs, and is available as a free download on almost every platform.
With a runtime the size of JRE 1.4+, there's little advantage over shipping your compiler with your package
You are confusing compiler with runtime. The JRE1.4+ runtime is just over 10mb. And, hey, you need to install it once for all java apps.
What is the
What you're missing is that the JVM, in its quest for ultimate portability, defines a fixed 32-bit size for your common integer type. Meaning that java applications do not take advantage of 64 bit precision on 64 bit machines.
These are a set of statements that don't relate. Java, for compatibility, keeps the size of byte as 8 bits. Does this mean it can't take advantage of 64 bit processors? Of course not. There are ways to optimize all memory access with 64-bit moves as against 32-bit moves, and of course Java longs are 64-bit and Java doubles are 64-bit. The JVM can even recognise specific processors and make use of specific register sets to optimise code. All this is done at run time with no effort required from the developer.
Of course, if you want to personally keep and manage dozens of finely-tuned binaries for different versions of Intel 32-bit, 64-bit, MMX and AMD, that's up to you.
Doesn't work? Then perhaps native code has some advantages.
Why shouldn't it work? Why should size of the binary have any relevance?
You upgrade your JRE and half the features in your Java App stop working.
I you could give an example of where half the features (or indeed, any significant features) in a java app stop working when a JRE is upgraded then I might consider this a useful comment. Of course this doesn't happen. I'm not saying that nothing ever changes in an JRE upgrade, but for virtually all apps, it makes no difference. Even huge systems like Eclipse run perfectly well on the 1.3, 1.4 and 1.5 versions of Java.
openoffice with java takes 60+ seconds to start, and you think java is widespread?
Open office is not Java. Java can be used in open office to write extensions, and to provide links to database via JDBC, but Open Office will run perfectly well if you don't have Java installed.
If Open Office is slow, its because Open Office (written in C++) is slow.
All other points are either a draw or worse than C++.
Try this:
1. Get your compiled C++ Linux excutable. 2. FTP or SCP that binary to a machine running a different operating system. 3. Type the command to start the executable.
Doesn't work? Then perhaps Java does have some advantages.
OK, let's stick to the same operating system. You upgrade to a 64-bit processor. Does your executable automatically run 64-bit with optimisation? No? Another advantage for Java.
The volume of Java use on Linux can be judged by taking a look at the operating systems that Sun directly provides Java VMs for: Solaris, Windows and Linux. This has been going on for years, even before Sun's recent 'conversion' to Linux use. This was because of demand from Linux developers. It makes sense: Most server-side coding is now done in Java, and the fastest growing server operating system is Linux.
Why not try running scripting languages with Java? You can use Jython (Python in Java), Groovy, BeanShell (dynamically typed scripting Java) or Jacl (TCL in Java). This way you can pick the right tool for the job within the same application, and package it all up together.
Start up a JVM process and you'll find that it makes incredibly heavy use of resources.
As even the latest VMs can run in only a few megabytes of memory, and as (see recent slashdot stores) can give speeds comparable to C++, and the most recent VMs allow VM sharing - you can make use of the same VM for more than one program, you statement is false.
Unless we find some big loophole that allows us to get around relativity, the earth really is an island to itself, and while it may be one of millions, it is the only one that will ever have any significance whatsoever to us. That makes it pretty darn important in my eyes.
whenever I read something like this, I think of what somone living a couple of millenia ago would have thought of the Earth with its unreachable distant lands and mysterious and endless oceans. They would have thought that their village was isolated, and anyone from even a few hundred miles away was a strange outsider. They would have imagined distant lands filled with strange creatures. Sound familiar? Now we can communicate almost anywhere in the world in a few seconds, and travel around the globe in less than a day.
To say that the Earth is 'the only one that we will ever have' seems a very arrogant statement, as it suggests that we now know all we will ever know about the cosmos and space travel.
Even with relativity, the nearest stars are only years away. Sea voyages of years were common centuries ago. Even with what we know now, there is nothing to stop us exploring the nearest stars, and once we have started there....
Plus, the BBC doesn't have a very good record with Daleks. There aren't very many working models left
Well, in terms of the general safety of all galactic civilizations, isn't that rather a good thing? I always assumed that the Daleks were just pretend. I mean, if they really worked.....
They may not call it 'thick client', but if you need a heavyweight operating system client-side, its definitely 'thick'. Microsoft are pitching aspects of Longhorn as a kind of 'super-browser', with the Avalon graphics system running XAML.
This kind of thing could be serious for Microsoft. Their strategy is 'thick client' - the browser and other features are integrated into the operating system. If security issues remain while the browser becomes a fundamental part of future Windows use, their are in trouble.
JDIC sounds like Sun has finally gave up "100% pure Java" principle and allows Java developers to access native functionality easily.
You always have been able to do this. Its called JNI (Java Native Interface).
It totally ignores all UI provided by client OS
No it doesn't. You can cut and paste between Swing and the client OS. You can drag and drop between Swing and and client OS. You can access Client OS information, and Client OS Print Services. There are tools available that allow you to embed ActiveX components in Swing.
which means that text boxes and file dialogs never behave correctly in Swing.
Never behave correctly? I can enter text, cut, copy, paste, reformat, edit styled text and HTML.
The file dialogs allow me to search for files and directories, filter by file types, create new directories.
How is this not 'behaving correctly'?
This is why SWT reacts 3x quicker than Swing
Yes, SWT is a good product. However, the next release of Java (out September) allows Swing to be accelerated through the use of OpenGL. That should be fast.
It may have a few platforms but ubiquitous it isn't
Java is on at least Windows,.Net, MacOS, MacOS/X, Linux 32-bit, Linux 64-bit, BSD, OS/2 (yes, OS/2!), PalmOS, DG/UX, Tru64, OpenVMS, Reliant Unix, BS2000, HP-UX, Solaris, AIX, OS/390, OS/400, VM/ESA, Netware, Oracle embedded, DYNIX, Irix, Symbian, QNX, VxWorks, NextStep, OpenStep, OSF/1, DOS, AtheOS, RISC OS, ARMLinux, EPOC, GCOS, Windows CE, Psion Series 5, Plan 9, Sony Playstation (!).
How would you define 'few'?
but ubiquitous it isn't.
Java is pre-installed on 60-70% of all new PCs. The number of JRE kits manually downloaded from Sun's site alone is in the tens of millions. There are well over a 100,000,000 mobile phones out there with embedded java.
there are several things that I feel are "missing" from Java
You may want to look at next release of Java (now called Java 5). Its available in late Beta right now, and will be out in Sept. It has a lot more of the features of C#, such as enums and boxing/unboxing and metadata, and some nice new features such as OpenGL acceleration of GUIs, and shared VMs.
Since windows is more widely used than Java, by your argument, it's even better to be stuck on Windows. Ugh
I was questioning your use of the word 'viable'. I mean, its like questioning if Windows is a viable desktop system. You may not like it (I don't) but there is no questioning that it is viable.
I said "real, viable choice on the language". Are any of these real and viable?
Most, if not all of them. Java Python (Jython) has a good solid history, and Groovy has a lot of momentum. The Smalltalks aren't that great, but work as command-line. There is a lot of interest in porting languages to the JVM, as its so widely available.
Not a troll, I'm curious: which of these is usable for enterprise or carrier-class applications? For which of them can I purchase a support contract from a reputable company?
Lots of them. For example, there are commercial and fully-supported compilers for COBOL, Pascal, Modula and Oberon.
Others are open-source efforts.
Oh, I see. It will work on any platform as long as that platform is Java. Got it.
You asked if it was limited to a particular Desktop, not platform, didn't you?
JDNC/JDIC means you're stuck on Java (but without real, viable choice on the language).
Well, considering how widely used Java is, its a lot better than being stuck on Windows.
Anyway, who says you are stuck with Java? There are dozens of languages available on the Java VM, including Python, LISP, Basic, Prolog, Smalltalk, Groovy, Ada, Forth, Pascal, Modula-2, Oberon and COBOL.
The fundamental problem (IMHO) is that desktop component integration is limited to a single desktop.
It isn't. Just because its using code from a library labelled 'jdesktop' does not mean that it is in any way restricted to Java Desktop - if you read about it you will see it will work with any Java client system - application, Applet, or WebStart, on any platform.
but will I ever have (or need?) component integration across the three?
You have it automatically, as the system is portable.
You can extend the VS IDE, the ActiveState guys have a great Perl add-in which has intellisense and all new Perl project wizards.
What I meant was that the IDE should be open for casual developers to extend quickly and easily in the language they normal work in. It would have been great if, when VS was first introduced, you could easily add extensions to it in Visual Basic. Suppose you wanted to add an Edit menu item that linked to code to, for example, reformat your source. In the Smalltalk system, this is not only trivial, its expected practice, and a normal way to work. Visual Studio imposes a separation between the IDE extenders and component providers, and the casual developer. I think this is an arbitrary and unnecessary division. The thing is, its a fact of history that Gates saw and took an interest in IDEs that gave this kind of power to every developer, but when MS released Visual Studio it was (and still is to some extent) restrictive on what you can do and use. The big question is why?
I would assume that your smalltalk ide couldn't handle every case of edit-and-continue.
It can, and I do mean every case. The whole Smalltalk environment is a continuous series of executing processes, of which your 'application' is just one.
You guys need to give up looking down your noses at anyone who uses anything but (LISP/Smalltalk/insert other escoteric language here.)
I don't look down at other languages - in fact, I don't do Smalltalk development these days.
There is a reason all those languages have not been popular. They really don't address real world development issues.
Actually, Smalltalk was widely used at the end of the 80s, and still is used for real world development. For a time, it was touch-and-go whether Smalltalk or C++ would be the primary OO development language. Its a highly practical language for many situations, and is certainly not elitist. Unfortunately, the Smalltalk industry seemed to decide that high-pricing, awkward licencing, and forking the language was more important than widespread use, so it almost died out. Its better today, with good free implementations, like Squeak.
People use Microsoft development environments for a reason. It is because the complete package is there: an excellent dev environment, excellent help and online support, an installation system, top notch compilers and wide industry use.
Yes, I agree, these are good features of it, but I still feel strongly that people who don't have experience of something 'elitist' like Smalltalk at its best are not in a position to judge what is missing from something like Visual Studio. They think what they have is first-rate. Its good, but not that good.
Things are getting better, in terms of IDEs - IBMs VisualAge range was superb (after all, it was written in Smalltalk!), and Eclipse with its ability to execute and debug arbitrary code fragments is looking good, but they still aren't up to what many of us used years ago in terms of power and flexibility. At least, that's what I feel.
Slashdot Mirror
And what a shame that would be, all those CPU cycles currently going to the JVM ..
what are you talking about? the jvm is just a program like any other. What 'wrapper classes'? if you read recent slashdot articles you should have noticed that java is fast.
JVMs dont magically eat up cpu cycles or memory. Java can run on small embedded systems and mobile phones.
bash: java: command not found
Java is installed on 60-70% of all new PCs, and is available as a free download on almost every platform.
With a runtime the size of JRE 1.4+, there's little advantage over shipping your compiler with your package
You are confusing compiler with runtime. The JRE1.4+ runtime is just over 10mb. And, hey, you need to install it once for all java apps.
What is the
What you're missing is that the JVM, in its quest for ultimate portability, defines a fixed 32-bit size for your common integer type. Meaning that java applications do not take advantage of 64 bit precision on 64 bit machines.
These are a set of statements that don't relate.
Java, for compatibility, keeps the size of byte as 8 bits. Does this mean it can't take advantage of 64 bit processors? Of course not. There are ways to optimize all memory access with 64-bit moves as against 32-bit moves, and of course Java longs are
64-bit and Java doubles are 64-bit. The JVM can even recognise specific processors and make use of specific register sets to optimise code. All this is done at run time with no effort required from the developer.
Of course, if you want to personally keep and manage dozens of finely-tuned binaries for different versions of Intel 32-bit, 64-bit, MMX and AMD, that's up to you.
-download your 500 kb Java app
-try to run it
Doesn't work? Then perhaps native code has some advantages.
Why shouldn't it work? Why should size of the binary have any relevance?
You upgrade your JRE and half the features in your Java App stop working.
I you could give an example of where half the features (or indeed, any significant features) in
a java app stop working when a JRE is upgraded then I might consider this a useful comment. Of course this doesn't happen. I'm not saying that nothing ever changes in an JRE upgrade, but for virtually all apps, it makes no difference. Even huge systems like Eclipse run perfectly well on the 1.3, 1.4 and 1.5 versions of Java.
You don't really share a JVM, at least not on Sun's latest implementation
You are right.
What would we lose if all Linux Java apps suddenly disappeared?
The ability to develop for one of the most widely used server systems (Linux) in the most widely used server-side development language (Java).
openoffice with java takes 60+ seconds to start, and you think java is widespread?
Open office is not Java. Java can be used in open office to write extensions, and to provide links to database via JDBC, but Open Office will run perfectly well if you don't have Java installed.
If Open Office is slow, its because Open Office (written in C++) is slow.
All other points are either a draw or worse than C++.
Try this:
1. Get your compiled C++ Linux excutable.
2. FTP or SCP that binary to a machine running a different operating system.
3. Type the command to start the executable.
Doesn't work? Then perhaps Java does have some advantages.
OK, let's stick to the same operating system. You upgrade to a 64-bit processor. Does your executable automatically run 64-bit with optimisation? No? Another advantage for Java.
The volume of Java use on Linux can be judged by taking a look at the operating systems that Sun directly provides Java VMs for: Solaris, Windows and Linux. This has been going on for years, even before Sun's recent 'conversion' to Linux use. This was because of demand from Linux developers. It makes sense: Most server-side coding is now done in Java, and the fastest growing server operating system is Linux.
I use scripting languages
Why not try running scripting languages with Java? You can use Jython (Python in Java), Groovy, BeanShell (dynamically typed scripting Java) or Jacl (TCL in Java). This way you can pick the right tool for the job within the same application, and package it all up together.
Start up a JVM process and you'll find that it makes incredibly heavy use of resources.
As even the latest VMs can run in only a few megabytes of memory, and as (see recent slashdot stores) can give speeds comparable to C++, and the most recent VMs allow VM sharing - you can make use of the same VM for more than one program, you statement is false.
Unless we find some big loophole that allows us to get around relativity, the earth really is an island to itself, and while it may be one of millions, it is the only one that will ever have any significance whatsoever to us. That makes it pretty darn important in my eyes.
whenever I read something like this, I think of what somone living a couple of millenia ago would have thought of the Earth with its unreachable distant lands and mysterious and endless oceans. They would have thought that their village was isolated, and anyone from even a few hundred miles away was a strange outsider. They would have imagined distant lands filled with strange creatures. Sound familiar? Now we can communicate almost anywhere in the world in a few seconds, and travel around the globe in less than a day.
To say that the Earth is 'the only one that we will ever have' seems a very arrogant statement, as it suggests that we now know all we will ever know about the cosmos and space travel.
Even with relativity, the nearest stars are only years away. Sea voyages of years were common centuries ago. Even with what we know now, there is nothing to stop us exploring the nearest stars, and once we have started there....
Plus, the BBC doesn't have a very good record with Daleks. There aren't very many working models left
Well, in terms of the general safety of all galactic civilizations, isn't that rather a good thing? I always assumed that the Daleks were just pretend. I mean, if they really worked.....
http://www.infoworld.com/article/03/10/31/43NNpdc_ 1.html
"Longhorn backs thick client model."
They may not call it 'thick client', but if you need a heavyweight operating system client-side, its definitely 'thick'. Microsoft are pitching aspects of Longhorn as a kind of 'super-browser', with the Avalon graphics system running XAML.
This kind of thing could be serious for Microsoft. Their strategy is 'thick client' - the browser and other features are integrated into the operating system. If security issues remain while the browser becomes a fundamental part of future Windows use, their are in trouble.
JDIC sounds like Sun has finally gave up "100% pure Java" principle and allows Java developers to access native functionality easily.
You always have been able to do this. Its called JNI (Java Native Interface).
It totally ignores all UI provided by client OS
No it doesn't. You can cut and paste between Swing and the client OS. You can drag and drop between Swing and and client OS. You can access Client OS information, and Client OS Print Services. There are tools available that allow you to embed ActiveX components in Swing.
which means that text boxes and file dialogs never behave correctly in Swing.
Never behave correctly? I can enter text, cut, copy, paste, reformat, edit styled text and HTML.
The file dialogs allow me to search for files and directories, filter by file types, create new directories.
How is this not 'behaving correctly'?
This is why SWT reacts 3x quicker than Swing
Yes, SWT is a good product. However, the next release of Java (out September) allows Swing to be accelerated through the use of OpenGL. That should be fast.
When it's running on my terminal
sourceforge.net/projects/javacurses
"Provides the classes necessary to create a text based Java application with colors, attributes and windows."
It runs on your terminal.
It may have a few platforms but ubiquitous it isn't
.Net, MacOS, MacOS/X, Linux 32-bit, Linux 64-bit, BSD, OS/2 (yes, OS/2!), PalmOS, DG/UX, Tru64, OpenVMS, Reliant Unix, BS2000, HP-UX, Solaris, AIX, OS/390, OS/400, VM/ESA, Netware, Oracle embedded, DYNIX, Irix, Symbian, QNX, VxWorks, NextStep, OpenStep, OSF/1, DOS, AtheOS, RISC OS, ARMLinux, EPOC, GCOS, Windows CE, Psion Series 5, Plan 9, Sony Playstation (!).
Java is on at least Windows,
How would you define 'few'?
but ubiquitous it isn't.
Java is pre-installed on 60-70% of all new PCs. The number of JRE kits manually downloaded from Sun's site alone is in the tens of millions. There are well over a 100,000,000 mobile phones out there with embedded java.
How would you define 'ubiquitous'?
Which does not mean it's not possible to do nasty stuff anyway.
Nothing is ever impossible, but its very, very difficult, because of in-build security.
Mobile phone worms anyone?
The mobile phone worms are nothing to do with Java. The proof-of-concept was code that used the raw Symbian OS.
there are several things that I feel are "missing" from Java
You may want to look at next release of Java (now called Java 5). Its available in late Beta right now, and will be out in Sept. It has a lot more of the features of C#, such as enums and boxing/unboxing and metadata, and some nice new features such as OpenGL acceleration of GUIs, and shared VMs.
Since windows is more widely used than Java, by your argument, it's even better to be stuck on Windows. Ugh
I was questioning your use of the word 'viable'. I mean, its like questioning if Windows is a viable desktop system. You may not like it (I don't) but there is no questioning that it is viable.
I said "real, viable choice on the language". Are any of these real and viable?
Most, if not all of them. Java Python (Jython) has a good solid history, and Groovy has a lot of momentum. The Smalltalks aren't that great, but work as command-line. There is a lot of interest in porting languages to the JVM, as its so widely available.
Not a troll, I'm curious: which of these is usable for enterprise or carrier-class applications? For which of them can I purchase a support contract from a reputable company?
Lots of them. For example, there are commercial and fully-supported compilers for COBOL, Pascal, Modula and Oberon.
Others are open-source efforts.
Oh, I see. It will work on any platform as long as that platform is Java. Got it.
You asked if it was limited to a particular Desktop, not platform, didn't you?
JDNC/JDIC means you're stuck on Java (but without real, viable choice on the language).
Well, considering how widely used Java is, its a lot better than being stuck on Windows.
Anyway, who says you are stuck with Java? There are dozens of languages available on the Java VM, including Python, LISP, Basic, Prolog, Smalltalk, Groovy, Ada, Forth, Pascal, Modula-2, Oberon and COBOL.
The fundamental problem (IMHO) is that desktop component integration is limited to a single desktop.
It isn't. Just because its using code from a library labelled 'jdesktop' does not mean that it is in any way restricted to Java Desktop - if you read about it you will see it will work with any Java client system - application, Applet, or WebStart, on any platform.
but will I ever have (or need?) component integration across the three?
You have it automatically, as the system is portable.
Er no. This is Java. Unlike ActiveX, its designed not to do nasty things.
You can extend the VS IDE, the ActiveState guys have a great Perl add-in which has intellisense and all new Perl project wizards.
What I meant was that the IDE should be open for casual developers to extend quickly and easily in the language they normal work in. It would have been great if, when VS was first introduced, you could easily add extensions to it in Visual Basic. Suppose you wanted to add an Edit menu item that linked to code to, for example, reformat your source. In the Smalltalk system, this is not only trivial, its expected practice, and a normal way to work. Visual Studio imposes a separation between the IDE extenders and component providers, and the casual developer. I think this is an arbitrary and unnecessary division. The thing is, its a fact of history that Gates saw and took an interest in IDEs that gave this kind of power to every developer, but when MS released Visual Studio it was (and still is to some extent) restrictive on what you can do and use. The big question is why?
Well, yes, and Borland/Turbo Pascal for Windows before it.
I would assume that your smalltalk ide couldn't handle every case of edit-and-continue.
It can, and I do mean every case. The whole Smalltalk environment is a continuous series of executing processes, of which your 'application' is just one.
You guys need to give up looking down your noses at anyone who uses anything but (LISP/Smalltalk/insert other escoteric language here.)
I don't look down at other languages - in fact, I don't do Smalltalk development these days.
There is a reason all those languages have not been popular. They really don't address real world development issues.
Actually, Smalltalk was widely used at the end of the 80s, and still is used for real world development. For a time, it was touch-and-go whether Smalltalk or C++ would be the primary OO development language. Its a highly practical language for many situations, and is certainly not elitist. Unfortunately, the Smalltalk industry seemed to decide that high-pricing, awkward licencing, and forking the language was more important than widespread use, so it almost died out. Its better today, with good free implementations, like Squeak.
People use Microsoft development environments for a reason. It is because the complete package is there: an excellent dev environment, excellent help and online support, an installation system, top notch compilers and wide industry use.
Yes, I agree, these are good features of it, but I still feel strongly that people who don't have experience of something 'elitist' like Smalltalk at its best are not in a position to judge what is missing from something like Visual Studio. They think what they have is first-rate. Its good, but not that good.
Things are getting better, in terms of IDEs - IBMs VisualAge range was superb (after all, it was written in Smalltalk!), and Eclipse with its ability to execute and debug arbitrary code fragments is looking good, but they still aren't up to what many of us used years ago in terms of power and flexibility. At least, that's what I feel.