Well, they really did clone the log4j API (with a few exceptions here and there), changed all of the names, and added a bunch of log-levels that no one will ever use. You can probably write a sed script to translate between the two packages.
So if they did clone the API, and switching between standard logging and log4j is a matter of running a simple script against my codebase, then what is the problem?
Considering that probably most object oriented frameworks use something that can be characterized as 'object managers' then I bet Bill Gates *does* do it already.
The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.
Then why on earth would they be upset? I never understood this line of thinking... if their product is better, people will use it. I for one am happy that there is finally a standardized approach to logging. If it seems it doesn't do enough to fit my requirements then I'll use some 3rd party logging package.
Because, in theory, you can optimize the code better at run-time than you can at compile time. This is how the HotSpot compilers work for instance. They look for 'hot spots' -- places in code that are executed the most times (the code inside loops etc) and try to optimize the hell out of that piece using the runtime information available to them (such as how many times the code is being run, interning methods and so forth).
This allows the same binary also to run optimally regardless of hardware. For instance, there was one benchmark (posted on Slashdot as well) that showed a program with growing datastructures that suddenly dropped performance after the growth had exceeded a given point. It turned out that was when the internal cache of the CPU ran out and the data had to be accessed from external caches. Statically compiled languages (C++ in this case) were not able to deal with this issue where as a HotSpot based Java code gradually optimized itself to the new conditions and ended up performing better than its C++ counterpart.
This is why a optimizing runtime compiler is a big deal especially on the server side. For desktop apps the startup time and small memory footprint is more crucial.
In essence.NET and C# are full of ideas borrowed from JAVA, DELPHI, DCOM etc. Why not pull an MS here and embrace your enemies.
Why not use Java and J2EE instead? There's already several years of Open Source development effort done for the platform and.NET is not bringing that much new to the table.
So do EXE files. Its less common OS's where more problems show up.
And why is this? As an exmaple, look at all that IBM has done with Java -- they're running it pretty much across their whole server hardware, ranging from modern operating systems to old legacy mainframes. The fact is that "less common" OS's can have a good Java support. If you don't see it, it is hardly the fault of Java the language or runtime but the quality of the implementation of the virtual machine and the expertise of the people who implemented it.
I'm talking about the Swing toolkit
Nothing in Java forces you to use Swing. The native widget peers still exist in AWT, and for example IBM has built new widget library (SWT) that uses native widgets only.
Again, it is the choice a developer makes. I have built Java GUI applications in pre-Swing times using AWT, and I still remember the pain of trying to get it to work consistently across both Windows and Linux. I will not go back to that and will keep using Swing as it is truly a portable GUI framework. However, if a developer wishes to take an advantage of native widget peers, it's possible and it is being done by some projects (see Eclipse for example).
and yet their applet works in very awkward ways on different platforms
Applets have always had their problems and probably always will, but again this has very very little to do with Java as most Java development is not in applets today. The problem with applets is the piss poor and mostly outdated JVM's embedded in the browsers. Java Plug-in may have helped the problem, I don't know, but I think its only available for IE and Netscape. Anyway, I think more modern browser have learnt the lesson and use a JRE from third parties that do actually work and are compatible.
Fine on Windows, yet quite problematic on some Linuxes, throwing Null exceptions, and fine on others.
Like I said, a problem of the browser having incompatible JVM and runtime libraries, most likely. Moving Java binaries from Windows to Linux has rarely been a problem to me when using a JRE ( except Linux JVMs being sometimes rather quick to Seg Fault because of inmature implementations).
In my experience Java works very reliably across platforms as long as you use mature and compatible virtual machines.
I suppose the C# port will come with the runtime and its libraries, and if not you are completely right
Many applications will need for example some kind of database connectivity. Developing C# on Win32 platform using Microsoft tools this is achieved using ADO+. Microsoft has no intention of opening ADO or standardizing it, so how will that application work on a Linux system? It won't. That's why the whole C# approach seems very uninteresting to me. You will get Win32 C# apps and Linux C# apps but you cannot move these application across platforms without a significant porting effort.
Since a major development effort for a game of this type is on the server side, I wouldn't go as far as saying C# is the best tool available. It certainly has nothing to do with the 90% client side share of Microsoft Windows.
I would definitely advice against using anything Win32 specific on the server side. It's just plain common sense to avoid limiting yourself to Wintel servers.
Java never seems to run very well on any given platform.
It runs just fine on my Windows.
It always looks and feels awkward, and never 'fits in' the platform it runs on.
Eh? What are you talking about?
* It doesn't seem to really be that 'portable' in the sense that Java programs often seem to work in unexpected ways on different platforms
Having written server software in Java for the past 3 years can't say I've really seen this. I'm still amazed by the fact that I can drop my binaries on the occasional Linux or Solaris box and it just works. It's definately more portable than anything else I've worked with. Most often portability comes down to the experience of the programmer. Java doesn't prevent a newbie from being stupid and screw up portability.
* He can probably compile C# down to any platform he wants to, as Linux seems to have C# compilation support, and other platforms will probably have this soon.
It's not the language thats important, its the libraries. Java has them, C# doesn't have them outside the Win32 platform.
There used to be a large cost of having more children, because you'd need to find enough food to keep them alive. This has changed since society will provide for the children even if the parents themselves can't.
umm, so how come in societes that can afford to provide for the children (even if the parents themselves can't) the birth rate is getting lower and not higher? Why isn't every woman in a developed country walking around with 20 kids?
Before anyone takes the creationist ideas too seriously (I personally believe them to be nothing but pseudo-science) you should read up on some background.
Well, your so called statistics also show only 9 Visual Basic projects. These "statistics" are of the same quality as the C Advocacy article. Totally worthless.
AFAIK, jboss is not a packaged product but more of a composite server (the container itself, JMX, messaging, queuing...) I guess that you'd need 10s, possibly 100s of downloads in order to have a production-ready framework.
Uhh, no you don't. You'd find out this yourself if you ever actually downloaded the product. It's one download, two if you want to have both servlet engines prepackaged.
Do notice though, that many of the "analysts" measure the market by direct license revenue
Independent research by Gartner Dataquest shows that BEA holds 41% of the new direct license revenue in the application server software market in 2000, a figure that is 10 share points higher than its closest competitor.
The Gartner market analysis revealed the following market share results:
BEA - 41%
IBM - 31%
iPlanet - 13%
Oracle - 4%
HP Bluestone - 4%
JBoss does not show up here because the server code itself does not generate any revenues.
I don't know how much physics you've taken but the math behind a bridge is complex and it's really easy to make a mistake.
I am sure the math is very very complex, and that it is very very easy to make a mistake. That's not the point however. The math behind the bridge design can be proven either correct or wrong. The math we use have been known for centuries.
Proving a software implementation correct has turned out to be alot more difficult task though. Otherwise the software engineers of today would be constructing the proofs routinely, instead of trying to rely on all sorts of different kinds of testing methods.
A properly designed program is inherently flawless because it was designed before it was implemented.
The software engineering field is filled with countless examples of heavy "design first" approach to implementing software. The practice has shown it does not guarantee flawless programs.
If you know each module performs its task and only its task and does it properly, the software won't crash!
Nice theory, but wrong. Why do we have "integration testing" then?
So you'd better make damn sure you get it 100% correct.
Please give examples of software in use today that have been proven 100% correct. I'd be curious to know how many actually exist.
I can definetly tell you that designing & building bridges is harder than designing and building software!
I think not. Building software with the assumption that its correctness is not verified or guaranteed is easy. So is building a bridge if I don't have to take account the calculus, but will rely on common sense ("it looks strong enough, I'm sure it'll hold" -- mind you, this is the attitude we use with building the consumer software today).
If you put the same requirements on consumer software that we put on bridges today (in other words, 100% correctness) then verifying the software will be alot more complex than verifying a design of a bridge.
Well, you can do the same with software.
There's a problem in putting this in practice. Otherwise we wouldn't have satellites worth billions of dollars explode if it was a simple matter to verify the correctness of the software.
However, a civil engineer CAN'T test a bridge!
Yes, so? My point was that testing in software engineering is a cheap replacement for the lack of methods to verify the correctness of software. The civil engineers can build safe bridges without testing because they have a well known axioms they can base their proof of correctness on. This is what is lacking in software engineering.
If a city engineer put his stamp on the bridge design, then he is also liable, and perhaps the municipality he works for. Why should software be any different?
Because a) building a non-trivial piece of software is lot more complex than building a bridge b) we currently lack the tools to verify the correctness of a software implementation.
The city engineer can do the math to verify the bridge will hold and not collapse. A software engineer is not able to do the same. Testing will never guarantee 100% correctness of code.
Slashdot Mirror
Well, they really did clone the log4j API (with a few exceptions here and there), changed all of the names, and added a bunch of log-levels that no one will ever use. You can probably write a sed script to translate between the two packages.
So if they did clone the API, and switching between standard logging and log4j is a matter of running a simple script against my codebase, then what is the problem?
Considering that probably most object oriented frameworks use something that can be characterized as 'object managers' then I bet Bill Gates *does* do it already.
Then why on earth would they be upset? I never understood this line of thinking... if their product is better, people will use it. I for one am happy that there is finally a standardized approach to logging. If it seems it doesn't do enough to fit my requirements then I'll use some 3rd party logging package.
So they didn't clone the log4j API, big boo hoo.
This allows the same binary also to run optimally regardless of hardware. For instance, there was one benchmark (posted on Slashdot as well) that showed a program with growing datastructures that suddenly dropped performance after the growth had exceeded a given point. It turned out that was when the internal cache of the CPU ran out and the data had to be accessed from external caches. Statically compiled languages (C++ in this case) were not able to deal with this issue where as a HotSpot based Java code gradually optimized itself to the new conditions and ended up performing better than its C++ counterpart.
This is why a optimizing runtime compiler is a big deal especially on the server side. For desktop apps the startup time and small memory footprint is more crucial.
Why not use Java and J2EE instead? There's already several years of Open Source development effort done for the platform and .NET is not bringing that much new to the table.
And why is this? As an exmaple, look at all that IBM has done with Java -- they're running it pretty much across their whole server hardware, ranging from modern operating systems to old legacy mainframes. The fact is that "less common" OS's can have a good Java support. If you don't see it, it is hardly the fault of Java the language or runtime but the quality of the implementation of the virtual machine and the expertise of the people who implemented it.
I'm talking about the Swing toolkit
Nothing in Java forces you to use Swing. The native widget peers still exist in AWT, and for example IBM has built new widget library (SWT) that uses native widgets only.
Again, it is the choice a developer makes. I have built Java GUI applications in pre-Swing times using AWT, and I still remember the pain of trying to get it to work consistently across both Windows and Linux. I will not go back to that and will keep using Swing as it is truly a portable GUI framework. However, if a developer wishes to take an advantage of native widget peers, it's possible and it is being done by some projects (see Eclipse for example).
and yet their applet works in very awkward ways on different platforms
Applets have always had their problems and probably always will, but again this has very very little to do with Java as most Java development is not in applets today. The problem with applets is the piss poor and mostly outdated JVM's embedded in the browsers. Java Plug-in may have helped the problem, I don't know, but I think its only available for IE and Netscape. Anyway, I think more modern browser have learnt the lesson and use a JRE from third parties that do actually work and are compatible.
Fine on Windows, yet quite problematic on some Linuxes, throwing Null exceptions, and fine on others.
Like I said, a problem of the browser having incompatible JVM and runtime libraries, most likely. Moving Java binaries from Windows to Linux has rarely been a problem to me when using a JRE ( except Linux JVMs being sometimes rather quick to Seg Fault because of inmature implementations).
In my experience Java works very reliably across platforms as long as you use mature and compatible virtual machines.
I suppose the C# port will come with the runtime and its libraries, and if not you are completely right
Many applications will need for example some kind of database connectivity. Developing C# on Win32 platform using Microsoft tools this is achieved using ADO+. Microsoft has no intention of opening ADO or standardizing it, so how will that application work on a Linux system? It won't. That's why the whole C# approach seems very uninteresting to me. You will get Win32 C# apps and Linux C# apps but you cannot move these application across platforms without a significant porting effort.
I would definitely advice against using anything Win32 specific on the server side. It's just plain common sense to avoid limiting yourself to Wintel servers.
It runs just fine on my Windows.
It always looks and feels awkward, and never 'fits in' the platform it runs on.
Eh? What are you talking about?
* It doesn't seem to really be that 'portable' in the sense that Java programs often seem to work in unexpected ways on different platforms
Having written server software in Java for the past 3 years can't say I've really seen this. I'm still amazed by the fact that I can drop my binaries on the occasional Linux or Solaris box and it just works. It's definately more portable than anything else I've worked with. Most often portability comes down to the experience of the programmer. Java doesn't prevent a newbie from being stupid and screw up portability.
* He can probably compile C# down to any platform he wants to, as Linux seems to have C# compilation support, and other platforms will probably have this soon.
It's not the language thats important, its the libraries. Java has them, C# doesn't have them outside the Win32 platform.
TB didn't kill most native americans, smallpox did.
umm, so how come in societes that can afford to provide for the children (even if the parents themselves can't) the birth rate is getting lower and not higher? Why isn't every woman in a developed country walking around with 20 kids?
A Brief History of the Evolution and Creation Science Conflict
Many claims of evidence against evolution are in reality pseudo-science, and are easily refuted.
Six Flood Arguments Creationists Can't Answer
Is Creationism a viable scientific hypothesis ?
Well, your so called statistics also show only 9 Visual Basic projects. These "statistics" are of the same quality as the C Advocacy article. Totally worthless.
Hmm... if you count C# as a derivative of C then Java would probably fit into that category as well.
So Java became a language in search of home and found in the web browser. But it's never been more than a cult language outside this market.
Mr. Steve Oualline seems to be well in touch with reality and the industry direction, heh.
Advocate all you want but come on... surely you can do better than that.
But then I guess they'd run out of operating systems pretty quick -- but hey, some might consider that a good thing!
Uhh, no you don't. You'd find out this yourself if you ever actually downloaded the product. It's one download, two if you want to have both servlet engines prepackaged.
RMI/IIOP is in the works... not sure if it will make it into 3.0 but shouldn't be too far off.
To get some idea where things are going currently, you can check this article from JavaWorld:
The Art of EJB Deployment
Independent research by Gartner Dataquest shows that BEA holds 41% of the new direct license revenue in the application server software market in 2000, a figure that is 10 share points higher than its closest competitor.
The Gartner market analysis revealed the following market share results: BEA - 41% IBM - 31% iPlanet - 13% Oracle - 4% HP Bluestone - 4%
JBoss does not show up here because the server code itself does not generate any revenues.If your software crashes or otherwise doesn't work properly, you can sue the company that made it.
You could sue every software company that has ever existed. Software has bugs. Certifying Software Engineers is not going to change that fact.
I am sure the math is very very complex, and that it is very very easy to make a mistake. That's not the point however. The math behind the bridge design can be proven either correct or wrong. The math we use have been known for centuries.
Proving a software implementation correct has turned out to be alot more difficult task though. Otherwise the software engineers of today would be constructing the proofs routinely, instead of trying to rely on all sorts of different kinds of testing methods.
A properly designed program is inherently flawless because it was designed before it was implemented.
The software engineering field is filled with countless examples of heavy "design first" approach to implementing software. The practice has shown it does not guarantee flawless programs.
If you know each module performs its task and only its task and does it properly, the software won't crash!
Nice theory, but wrong. Why do we have "integration testing" then?
So you'd better make damn sure you get it 100% correct.
Please give examples of software in use today that have been proven 100% correct. I'd be curious to know how many actually exist.
I think not. Building software with the assumption that its correctness is not verified or guaranteed is easy. So is building a bridge if I don't have to take account the calculus, but will rely on common sense ("it looks strong enough, I'm sure it'll hold" -- mind you, this is the attitude we use with building the consumer software today).
If you put the same requirements on consumer software that we put on bridges today (in other words, 100% correctness) then verifying the software will be alot more complex than verifying a design of a bridge.
Well, you can do the same with software.
There's a problem in putting this in practice. Otherwise we wouldn't have satellites worth billions of dollars explode if it was a simple matter to verify the correctness of the software.
However, a civil engineer CAN'T test a bridge!
Yes, so? My point was that testing in software engineering is a cheap replacement for the lack of methods to verify the correctness of software. The civil engineers can build safe bridges without testing because they have a well known axioms they can base their proof of correctness on. This is what is lacking in software engineering.
Has there ever been a single piece of software that did not include at least one bug after its initial release?
If companies are going to get sued when their software is unstable, they wont make unstable software.
Define "unstable software".
Because a) building a non-trivial piece of software is lot more complex than building a bridge b) we currently lack the tools to verify the correctness of a software implementation.
The city engineer can do the math to verify the bridge will hold and not collapse. A software engineer is not able to do the same. Testing will never guarantee 100% correctness of code.
You're right. Let's give them a bunch of machines with MS-DOS installed only.