There is now a very effective non-proprietary persistence solution - Java Data Objects (JDO). This typically requires no more than a couple of supporting files in each application no matter how many classes you wish to store. Its far more powerful than EJB, with a portable query language and inheritance. There are many high-quality implementations of the javax.jdo.* classes.
J2EE is small and easy, not large and expensive. Anyone can build JSP pages or use Servlets on a free but high-quality App server like Tomcat - this may not involve Enterprise Java Beans (the least used aspect of J2EE), but its still J2EE and it costs nothing.
How can.Net be a threat when Microsoft is struggling (making a loss!) on the server side? Unless the Mono folks unwisely give Microsoft an escape route, the eventual rise of Linux on the desktop will squash.Net flat. This rise is starting: I develop websites for international use. If I deploy anything that requires Microsoft on the client (as do.Net apps), I soon get enough complaints to convince me otherwise!
Why does Java need to be Open Source to ride the Linux revolution? High-quality Java VMs are ready for Linux.
Java is the most widely requested language for development, and its use is still rapidly expanding. Sun has nothing to fear.
64-bit processors are better than 32-bit ones because 32-bit processors 'can't take advantage of more than 4 megabytes (sic) of memory at a time'.
Well, yes, but the real reason that 64-bit is better is that software should be able to move data around more quickly, typically twice as fast as 32-bit given a well-designed data bus external to the chip.
Don't you just love the accuracy of these reports? They don't just say '3%' they say '3.2%'. Maybe its just my experience with math and statistics, but I would be far more confident if someone said 'around 3%'. Of course, trying to predict as far ahead as 2007 is just a joke.
Having been installing and supporting MS products for a very long time, I would say that there is considerable risk in sticking with them. Over the past 10-15 years many enforced upgrades (to newer versions of office products for example) have required significant rewrites and porting efforts (the horrors of upgrading Access through several versions are well known). Open Source and Open Standards bring security and stability.
Microsoft shipped a deliberately crippled JVM that did not allow development of full-featured cross-platform applets. It was labelled 'Java', but was not Java. It was Microsoft's attempt to confine Java client development to Windows.
As for Java on the desktop, there is nothing to stop you shipping the JRE (a once-only install) with all your apps.
Evolution is falsifiable. All it takes is a human skeleton in a rock layer more than a few million years old....
Evolution (that organisms change with time as a result of alterations in genotype) is a simple and elegant fact that anyone can observe by picking up rocks and looking at the fossils. Its far stronger as a fact than atomic theory, as no-one really understands quantum mechanics.
They should just do what other have suggested and open source the language. They could take the UNIX(tm) approach and tell those who package up JDK's and JRE's that they can only use the "Java" trademark if they meet certain requirements.
This is exactly what they have done. You can download the source for Java right now, but you can ony call any mods Java if meet the tests.
They don't even seem to be making a profit on the language itself, why this obsessive desire to control it with an iron fist?
So they have an application deployment system that really is cross-platform, and does not end up horribly fragmented like C or C++. Developers can write to a known spec, on any platform and then deploy on almost any other platform, including Solaris. Its this flexibility that Sun make money from. With Java out there as the most popular development language, all those Java apps are automatically Solaris and Sparc compatible, and are also compatible with any future direction Sun may take (Linux/AMD, for example). Its a brilliant strategy. Code in Java, and protect your investment.
If Sun had 'opened up' Java, and not kept it controlled, this would not have been possible. Microsoft Java would have differed from HP Java and IBM Java.
Eclipse and netbeans/forte have different strengths and weaknesses and are in some ways, not even the same thing.
Mysteriously, Eclipse has no built-in support for client-side GUI development. For a product that was supposed to be pushing IBMs SWT GUI library, this is a serious weakness. You can get rather second-rate plugins for Eclipse to do this, but in contrast netbeans has a first-rate Swing GUI designer tool. (For those who don't think Swing is a useful GUI, look at its integration into MacOS/X). Another serious weakness in Eclipse is its lack of J2EE support as initially downloaded, whereas netbeans has full JSP/Servlet support, including debugging of JSP at the source level (as well as in the generated The strengths of Eclipse are its incremental compilation of products and refactoring tools.
People misunderstand what Eclipse is - its not really an IDE - its more a platform from which IDEs can be implemented via plugins. Netbeans as 'shipped' is a far more fully-featured IDE for Java development, but with the option for additional plugins to be added. This is because Netbeans has been around longer and more options are included in the base install.
Sun are right about this. Let people use Eclipse, and let them use Netbeans/Forte, and let there be a common API for plug-ins for both. If IBM had done the right thing and collaborated, features such as JSP support could have been loaded into Eclipse at the start.
One of the best examples of this is Jython - python implemented in 100% java. This allows the flexibility of a scripting language with the security and portability of Java.
Microsoft doesn't provide what users need, it provides what users think they want, and what managers think users want. These are very different things.
For example, very little functionality is really needed to produce a document, but look at Word in Office 2000/XP, which are apparently what users want. There is no real productivity gain in the production of 99% of all documents over Word Perfect 5.2 for DOS from nearly 20 years ago, yet Word is 100x bigger, requires 100x more memory and nearly 1000x more processor power.
Its not the JVM: VMs are small things that load in fractions of a second. Its the class libraries. Many of the standard class libraries supplied with VMs (such as the Swing GUI) have definitely been incompetently coded in terms of load speed, and are being extensively recoded because of this.
Any money spent on spacecraft, past or present is a tiny fraction of the gross national product of the United States. The money saved from a very slight cut in the defence budget could dramatically reduce poverty and starvation.
In the 70s shuttle prototypes weighing nearly 200,000 pounds were launched into landing test flights off the back of 747s. This is far more massive than the upper stage of a saturn 7.
What you say makes a lot of sense, but its an application organisation problem, not bloat. Slowness in starting is a problem in any application that dynamically loads and links code, either locally or over a network, not just Java. There is no reason, with competent coding, for a Java application to be slow or slow to start.
I remember the same arguments being used against C++ in the 80s.
What bloat with java virtual machines? you can run java on credit cards. Far better something portable at the binary level like Perl or Java than fixed compiled-for-one-platform C++ code.
The big question is why did a moon mission require a huge rocket like the Saturn V? The Thumping Big Rocket idea is a very inefficient and expensive way to get to space. A far better idea would have been to get most of the way to Earth orbit on the back of a plane. Planes use atmospheric oxygen to burn their fuel rather than carrying liquid oxygen with them like a rocket. The Saturn V was nothing more than a very big missile.
In what sense? If someone purchased a machine with win98 installed, is it suddenly going to stop working? Will the screen go blank, the printer stop?
Microsoft has an obligation to issue security patches for these older systems, as these correct faults in the package as supplied years ago. If the systems were shipped with sloppy code and buffer overruns they were not fully fit for the intended use.
A total switch to Linux would take decades. What IBM has to do along with Unix vendors is enhance cross platform tools that allow deployment of generic apps to either Linux or Win32. So IBM needs to support toolkits like Qt, Mono and Lindows... IBM needs to promote this area and get books on the shelves that help people write Win32/Linux apps.
IBM have been doing this for years. They provide an open source set of tools and a development platform called Eclipse. They write cross platform applications of Java. I realise that for some strange reason Slashdotters don't like to hear the J-word, but Java provides a pretty much ideal way to supply cross-platform apps and tools, especially with IBM's native GUI toolkit - SWT.
Yes - there is a fully documented Visual-Basic like language in Open/Star Office. For more sophisticated work you can write plug-ins to Open Office in C++ or Java or Python. If you use IBM's Java VMs you can get C-equivalent speed for numerical work.
Excel is frequently used as a front-end of calculations. The main numerical work is done in custom DLLs. I would not use in in this way, but it saves a lot of work in tabular and graphical presentation of results.
Slashdot Mirror
There is now a very effective non-proprietary persistence solution - Java Data Objects (JDO). This typically requires no more than a couple of supporting files in each application no matter how many classes you wish to store. Its far more powerful than EJB, with a portable query language and inheritance. There are many high-quality implementations of the javax.jdo.*
classes.
"Java will not really take off"??
Seems to be some kind of reality blockage somewhere. I look forward to future comments such as:
"Linux will not really become widespread until..."
"Windows will not dominate the desktop unless..."
Hint: Scan the job ads. Java has taken off.
Its full of contradictions and silly mistakes.
.Net be a threat when Microsoft is struggling (making a loss!) on the server side? Unless the Mono folks unwisely give Microsoft an escape route, the eventual rise of Linux on the desktop will squash .Net flat. This rise is starting: I develop websites for international use. If I deploy anything that requires Microsoft on the client (as do .Net apps), I soon get enough complaints to convince me otherwise!
J2EE is small and easy, not large and expensive. Anyone can build JSP pages or use Servlets on a free but high-quality App server like Tomcat - this may not involve Enterprise Java Beans (the least used aspect of J2EE), but its still J2EE and it costs nothing.
How can
Why does Java need to be Open Source to ride the Linux revolution? High-quality Java VMs are ready for Linux.
Java is the most widely requested language for development, and its use is still rapidly expanding. Sun has nothing to fear.
64-bit processors are better than 32-bit ones because 32-bit processors 'can't take advantage of more than 4 megabytes (sic) of memory at a time'.
Well, yes, but the real reason that 64-bit is better is that software should be able to move data around more quickly, typically twice as fast as 32-bit given a well-designed data bus external to the chip.
Don't you just love the accuracy of these reports? They don't just say '3%' they say '3.2%'. Maybe its just my experience with math and statistics, but I would be far more confident if someone said 'around 3%'. Of course, trying to predict as far ahead as 2007 is just a joke.
Having been installing and supporting MS products for a very long time, I would say that there is considerable risk in sticking with them. Over the past 10-15 years many enforced upgrades (to newer versions of office products for example) have required significant rewrites and porting efforts (the horrors of upgrading Access through several versions are well known). Open Source and Open Standards bring security and stability.
Microsoft shipped a deliberately crippled JVM that did not allow development of full-featured cross-platform applets. It was labelled 'Java', but was not Java. It was Microsoft's attempt to confine Java client development to Windows.
As for Java on the desktop, there is nothing to stop you shipping the JRE (a once-only install) with all your apps.
Evolution is falsifiable. All it takes is a human skeleton in a rock layer more than a few million years old....
Evolution (that organisms change with time as a result of alterations in genotype) is a simple and elegant fact that anyone can observe by picking up rocks and looking at the fossils. Its far stronger as a fact than atomic theory, as no-one really understands quantum mechanics.
They should just do what other have suggested and open source the language. They could take the UNIX(tm) approach and tell those who package up JDK's and JRE's that they can only use the "Java" trademark if they meet certain requirements.
This is exactly what they have done. You can download the source for Java right now, but you can ony call any mods Java if meet the tests.
They don't even seem to be making a profit on the language itself, why this obsessive desire to control it with an iron fist?
So they have an application deployment system that really is cross-platform, and does not end up horribly fragmented like C or C++. Developers can write to a known spec, on any platform and then deploy on almost any other platform, including Solaris. Its this flexibility that Sun make money from. With Java out there as the most popular development language, all those Java apps are automatically Solaris and Sparc compatible, and are also compatible with any future direction Sun may take (Linux/AMD, for example). Its a brilliant strategy. Code in Java, and protect your investment.
If Sun had 'opened up' Java, and not kept it controlled, this would not have been possible. Microsoft Java would have differed from HP Java and IBM Java.
Eclipse and netbeans/forte have different strengths and weaknesses and are in some ways, not even the same thing.
Mysteriously, Eclipse has no built-in support for client-side GUI development. For a product that was supposed to be pushing IBMs SWT GUI library, this is a serious weakness. You can get rather second-rate plugins for Eclipse to do this, but in contrast netbeans has a first-rate Swing GUI designer tool. (For those who don't think Swing is a useful GUI, look at its integration into MacOS/X). Another serious weakness in Eclipse is its lack of J2EE support as initially downloaded, whereas netbeans has full JSP/Servlet support, including debugging of JSP at the source level (as well as in the generated The strengths of Eclipse are its incremental compilation of products and refactoring tools.
People misunderstand what Eclipse is - its not really an IDE - its more a platform from which IDEs can be implemented via plugins. Netbeans as 'shipped' is a far more fully-featured IDE for Java development, but with the option for additional plugins to be added. This is because Netbeans has been around longer and more options are included in the base install.
Sun are right about this. Let people use Eclipse, and let them use Netbeans/Forte, and let there be a common API for plug-ins for both. If IBM had done the right thing and collaborated, features such as JSP support could have been loaded into Eclipse at the start.
integrates nicely with other languages.
One of the best examples of this is Jython - python implemented in 100% java. This allows the flexibility of a scripting language with the security and portability of Java.
Microsoft doesn't provide what users need, it provides what users think they want, and what managers think users want. These are very different things.
For example, very little functionality is really needed to produce a document, but look at Word in Office 2000/XP, which are apparently what users want. There is no real productivity gain in the production of 99% of all documents over Word Perfect 5.2 for DOS from nearly 20 years ago, yet Word is 100x bigger, requires 100x more memory and nearly 1000x more processor power.
Its not the JVM: VMs are small things that load in fractions of a second. Its the class libraries. Many of the standard class libraries supplied with VMs (such as the Swing GUI) have definitely been incompetently coded in terms of load speed, and are being extensively recoded because of this.
Any money spent on spacecraft, past or present is a tiny fraction of the gross national product of the United States. The money saved from a very slight cut in the defence budget could dramatically reduce poverty and starvation.
In the 70s shuttle prototypes weighing nearly 200,000 pounds were launched into landing test flights off the back of 747s. This is far more massive than the upper stage of a saturn 7.
What you say makes a lot of sense, but its an application organisation problem, not bloat. Slowness in starting is a problem in any application that dynamically loads and links code, either locally or over a network, not just Java. There is no reason, with competent coding, for a Java application to be slow or slow to start.
I remember the same arguments being used against C++ in the 80s.
What bloat with java virtual machines? you can run java on credit cards. Far better something portable at the binary level like Perl or Java than fixed compiled-for-one-platform C++ code.
What overhead is there with Java?
String name = request.getProperty("name");
seems pretty a lightweight way to get stuff from a web request.
The big question is why did a moon mission require a huge rocket like the Saturn V? The Thumping Big Rocket idea is a very inefficient and expensive way to get to space. A far better idea would have been to get most of the way to Earth orbit on the back of a plane. Planes use atmospheric oxygen to burn their fuel rather than carrying liquid oxygen with them like a rocket. The Saturn V was nothing more than a very big missile.
Microsoft shipped Internet Explorer 4.0 with Windows 98. Consumers had a choice then on whether or not to use IE... but they used IE.
Bundling reduces choice as most users will stick with the pre-installed software.
In what sense? If someone purchased a machine with win98 installed, is it suddenly going to stop working? Will the screen go blank, the printer stop?
Microsoft has an obligation to issue security patches for these older systems, as these correct faults in the package as supplied years ago. If the systems were shipped with sloppy code and buffer overruns they were not fully fit for the intended use.
A total switch to Linux would take decades. What IBM has to do along with Unix vendors is enhance cross platform tools that allow deployment of generic apps to either Linux or Win32. So IBM needs to support toolkits like Qt, Mono and Lindows... IBM needs to promote this area and get books on the shelves that help people write Win32/Linux apps.
IBM have been doing this for years. They provide an open source set of tools and a development platform called Eclipse. They write cross platform applications of Java. I realise that for some strange reason Slashdotters don't like to hear the J-word, but Java provides a pretty much ideal way to supply cross-platform apps and tools, especially with IBM's native GUI toolkit - SWT.
Yes - there is a fully documented Visual-Basic like language in Open/Star Office. For more sophisticated work you can write plug-ins to Open Office in C++ or Java or Python. If you use IBM's Java VMs you can get C-equivalent speed for numerical work.
Excel is frequently used as a front-end of calculations. The main numerical work is done in custom DLLs. I would not use in in this way, but it saves a lot of work in tabular and graphical presentation of results.