I agree with your strategy, but I would suggest changes to your suggested frameworks:
Don't use Hibernate, use JDO (Java Data Objects). Hibernate is a great product, but it's single-vendor and a proprietary API. JDO is a standard, with 30 competing vendors, some open-source, and is better designed to cope with larger systems.
Don't use Struts (or just Struts), use JSF(Java Server Faces). This transition is recommended by the creator of Struts. JSF is much simpler to code for, and is a standard API that is being widely accepted by different vendors (you can include free JSF components from, say, Sun and Oracle in the same application). There are visual form designers to speed development.
If you are developing large projects, it makes sense to develop to standards that allow you to switch between competing (possibly commercial) products.
I am beginning to suspect that Intel does things like this simply to make x86's instruction set harder and harder to emulate well.
Why should this have anything to do with the instruction set? The principle is exactly the same as for existing multi-processor systems, but on the same chip.
Just curious, but how is PHP better in code gluing?
I thought Java's inherit OOP design would make it easier to integrate code, whereas PHP only recently supported "real" OOP in PHP5.
I have recently discovered the Spring system for Java (www.springframework.org) It is a huge system, but you need only use the parts you need. I use the it as a way of managing settings for my applications (to avoid having to load in lots of properties files) and to glue parts of the my code together. It's very easy to use for this.
While your experiences with PHP may have limited it to small environments, ours proves PHP can scale quite easily.
I didn't mean that it would not scale in terms of bandwidth (although my feeling is that with servlet/JSP, where you end up with hotspot-optimised native code, is always going to be faster than interpreted PHP), but I would suggest that PHP does not always scale well in terms of application size. It sounds like that is not relevant to you.
I think one thing we can agree on is that it's all based on the code behind the scenes, no matter what the environment.
PHP is straightforward and easy, and most distributions have their own packages for it. Whereas with Java, the initial set up is overwhelming for beginners.
Interesting. I have found the exact opposite: it can be a real struggle to uninstall the default (minimal) installations of apache and PHP from many distros, in order to recompile and re-install these packages to allow anything but the simplest PHP applications to run.
On the other hand, Java is a simple RPM, and tomcat is just a gzip/untar...
Yeah, then spend 6 hours wrestling with mod_jk so it will play nice behind Apache.
Or just use simple redirects (a few lines in httpd.conf).
Its either that or use Tomcat to serve your static files, which is silly, if you have any traffic.
Why? Tomcat + Java is fast. Not as fast as Apache alone, true. But anyway, the answer is simple: put static content in a directory which is not subject to a redirect to Tomcat.
You don't need to use Apache at all - doing so is only a matter of convenience or preference. My point was about what you have to do to get PHP working (at least on some distros). There is a big difference.
Tomcat could be the best software on the face of the Earth, with the easiest install ever devised. Unfortunately we quit using Tomcat over two years ago after we saw it running 100 threads and using 1GB of memory (with a Java imposed memory limit in place). Not even Oracle uses that much memory, and this is just a webserver we're talking about. Nobody could come up with a single argument not to give it the axe, so away it went.
There are two reasons why this can happen: Naively written java code (JSPs or Servlets) can bring data in and store it in session-scope rather than request-scope. As sessions can last for a long time (say, 30 minutes), you soon end up with lots of memory use (been there, done that!). The other reason is inappropriate configuration of the Java VM and tomcat. The maximum number of threads is a single setting in the server.xml file - easy to change. If you are only doing minor work in each request, turn down the memory allocation: this can be set using JAVA_OPTS.
Having a large number of threads should not be an issue - the Java VM is designed to handle this easily.
The argument for not giving it the axe is plain (in my opinion): Code carefully, and tomcat/J2EE will give you very scalable applications - not just in terms of the number of users, but to allow for significant expansion of the code size.
However, if you are really only adding minor code to web pages, PHP will do fine.
Yup, because it is a *LOT* harder to install, and administer. It's all scary black magic, and down right confusing.
Er. Download tomcat. gunzip and untar. place JAVA_HOME into catalina.sh. Set a manager account in the config file. Start it up. It's one of the easiest installs I have ever done.
Installing, starting, and stopping individual web apps is all done with a simple web interface. It's one of the easiest systems to administrate I have used.
Compare to PHP, where on some Linux distros the only way to get it working is to compile it yourself, along with specific versions of apache.
Tomcat also has the advantage that its trivially simple to run everything as non-root, for security: You just untar it into a user account and start it there!
Is this really a major climate change or just part of the normal variation in weather. We don't know. Why? We don't have enough data yet. Even in places like London, accurate weather records stretch back less than 200 years. Records of global weather are only a few decades old.
Not quite - this is true for accurate records, but we have broad knowledge of a far longer period. The last millenium has been unusually stable. Even a slight change in climate, even for a short while, would be disastrous if we don't prepare for it. Climate is going to change dramatically sometime soon anyway, as part of natural processes, whether we minimise human influence or not.
Even normal variations in climate could threaten millions of lives - after all, the normal climate over the past few million years is ice age.
So relax, the chances of anything like this happening in your lifetime is vanishingly small.
Too late. The climate change is already under way. Increased heat waves in Europe, increased hurricane frequency, thinning of ice caps, retreating glaciers. Whether or not this is due to human activity, its happening. Now.
Glaciers, for those who haven't guessed, don't sit in neutral...so unless its an ice age, they are gonna be retreating.
How do you work this out? Of course glaciers can sit in 'neutral'. They may grow a few metres one year, and shrink back another year, but on average stay that same.
You can obfuscate XML content just as easily as you do with binary structures, while still having a perfectly valid XML document.
So what?
With XML you have to put work into obfuscating it, and you have the possibility of having a clear and reasonably self-documenting format.
With binary formats its already obfuscated from the start. If I hand someone a binary file, were is the built-in indication of endian-ness, work length, data labelling or structure?
Other components like Windows.Forms, Directory.Services, Enterprise Services and JScript are being developed but are not as mature as the other components but are under development by various people.
Yes, I have seen that page. It's the same page that mentions that some of the enterprise services are likely to remain unsupported!
That page gives a definite emphasis on the intended use of Mono: the 'open source desktop'. Well, fine! That's actually what a lot of.Net is being used for. But, a large number of developers (perhaps the majority) develop server-side, and stable enterprise APIs are important to at least some of us. It's neither practical or sensible to start developing with Mono hoping that certain parts of the enterprise features will be stable and complete sometime soon (especially when their website gives contradictory information). The choice for stable enterprise features is currently between Microsoft.Net or J2EE. If you want portability, it has to be J2EE.
Both of these quotes appear to be out of context, i'm not even sure where the first one comes from and the second one is in respect to running VisualStudio.NET programs under the current version of mono.
They are not out of context. They are taken directly from the Mono roadmap page:
http://www.mono-project.com/about/mono-roadmap.h tm l
The second is not in respect to VisualStudio.Net programs. Its a general statement. VisualStudio.Net is not mentioned in that context at all.
when mono 2.0 is finished, you should be able to run anything not depending on something in the Microsoft.* namespace.
This is contradicted by the Mono website!
I quote:
Although WinFS, Avalon and Indigo are very exciting components, at this time it is too early to tell when those components will be available for Mono.
and:
Unsupported technologies
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.
System.EnterpriseServices and System.Management come to mind, and we are unlikely to put any resources into the task. We would gladly host the code if someone cares to implement it, but they would likely remain unsupported features of Mono.
According to Microsoft, System.EnterpriseServices "provides an important infrastructure for enterprise applications" and System.Management "allow management software to diagnose and correct problems in an enterprise computing environment".
This functionality is NOT absent in J2EE implementations. Namespaces such as javax.management are available in all J2EE app servers, including JBoss, the open source implementation.
And I can certainly respect your point about porting legacy systems to new technologies being a pain, but hey, it gives you a job (hehe).
heh - and a lot of others too!
I guess what chaps me the most about everybodies anti MS sediments is the fact that MS DOES provide good technologies, but nobody ever gives them the credit.
I agree that when they do things, they do things well. My grouch with them is based on nearly 30 years (!) of using their products (I used their cassette-tape-based Macro Assembler for Z80 in the 70s). They always seem to play catch-up with other technologies then act as if they invented them! From Windowing to Object Orientation. I remember a recent note on their website regarding the addition of inheritance to Visual Basic in VB.Net as 'Innovative'! Excuse me! I was using inheritance in Smalltalk 20 years ago! They could easily have added full object-orientation to Visual Basic a decade before and made things easier for developers, but chose not to, for marketing reasons. Its their combination of arrogance and nerve that gets to me.
Ok, you see like a reasonable fellow compared to the normal slashdork fangirls we see around here so I had a knee-jerk reaction to you and apologize.
That is very decent of you - thanks!
It's not that Java is bad. It's that Sun's stewardship of Java has been bad. All the way from McNealy screaming in the late 90s that Java was the platform and the OS was irrelevant to the disaster that is Swing.
I certainly agree with you in most respects here. Sun have never been good at knowing how to pitch Java. It should never have been released when it was, when it was slow and buggy.
Swing was absolutely a disaster when it was released - I simply couldn't believe people would write applications that had an interface so slow! Now it is vastly better, with the ability to use OpenGL acceleration. I think you can now write very reasonable applications in Swing, but it has taken a long time to get there!
As for J2EE: There are good bits and bad bits. The bad bits are the enterprise Java beans - cumbersome and hard to debug. The good bits (I think) are the JSP/Servlet parts, and the message queue features.
My personal like of Java is that no matter how bad Sun's implementation of things, you have a choice: if you don't like parts of J2EE, use replacements for it such as Spring.
The only missing bits are going to be the Microsoft.* namespace. This is insignificant.
If this is going to be the case soon, I'm certainly going to be more interested in Mono, although I'd still be very nervous about what MS would do if Mono got really successful.
Oh really? What kind of support? I'm somehow entitled to talk to a support engineer from Sun because I download the SDK? Or are you talking abut a support contract?
Support contract. You can buy support for Java from Sun.
And how old is mono? mono is just starting up, their goal isnt even to get api compatibility untill 2.0
A good reason to hold off using it for large-scale and business critical applications.
and people are running mono in production environments with xsp already.
Yes, but this STILL does not answer my point about incomplete APIs. I wish Mono well, and hope it takes off as a popular and successful development platform: an open-source and robust competitor to Java would be a great idea. But, it should stand on its own - and not try to be what it can never be - a full cross-platform implementation of Microsoft.Net.
but just as much as Java has failed with "write once run anywhere
I think that almost all current Java developers would disagree with you here! Almost all the tools I use for Java development and all the libraries I use are completely platform neutral. In the early days there were serious platform-dependencies (there were thread issues on Linux for example), but those days are long past. I routinely transfer major projects between Windows, Solaris and Linux with no effort at all.
Eventually way downt he road.NET will be dropped and they will release somthing new, but that's fine,
Those of us (like me) who spend a significant part of their time struggling to port legacy code to something modern and supportable learn to worry about such dropping of technologies. Java, for all its many faults, has been designed to be around for decades.
Can anybody admit though that virtually everything in the Java 1.5 release was just catching up to where C# is now?
I won't agree! There are huge new features in Java 1.5 with have nothing to do with C# - additions to the threading libraries, GUI enhancements etc. Generics have been under development for a very long time in Java (before C#) and are done in a different way. Annotations are, I agree, a catch-up feature (and very welcome).
however the only concern i believe is that in case of an accident there could be a terrible disaster before the reaction becomes stable. ofcourse its a remote possibility, though...
The really good thing about fusion reactors as against fission is that they are very safe, and won't cause disasters. The amount of energy contained in the reactor at any instant is small (especially compared with all the energy in the core of a fisson system!). If anything goes wrong with a fusion reactor, bits of it burn out and it needs some repair, and that's all.
Well, it's available as packages for Linux, Windows, and MacOS/X. I would imagine that it would compile for many other platforms, such as Solaris and BSDs (that's 5!). I would be surprised to see a version for OpenVMS or zOS.
This comparison is irrelevant anyway - it's not answering my point about incomplete APIs in Mono.
Oh, I understand how bitter you and the other rabid microsoft haters are that Mono and dotGNU was even started.
Not bitter, just puzzled. Why copy Microsoft? All that expertise could have gone into an entirely new bytecode/runtime/language combination - something that could never be threatened by patents or trying to catch a moving target.
I find it bizarre that so many developers who don't like Java (because of licencing) are prepared to work on duplicating Microsoft technologies. In the past, anyone who has come anywhere developing a successful clone of a Microsoft product as either been sued or bought out. That is not an emotional response, or Microsoft-hating, its all on the record.
And the most infuriating thing for the linux fangirls is that many Gnome developers actually like Mono/Gtk#.
Why should it be infuriating? Mono/Gtk# is a great technology, and has come far in a short time. Good luck to it! It would be great if Mono became a high-quality standard for cross-platform enterprise applications. Guess what! It runs Java too!
My point is that it is NOT.Net: significant bits are missing, and are always likely to be.
It looks like you've drunk the Sun koolaid regarding cross-platform. dotGNU already runs on more platforms than any Sun implementation of Java.
How is this relevant to anything? The Sun implementation of Java runs on far more platforms than the Microsoft implementation of.Net. So what? This is of no relevance to the discussion at all. Java (all implementations) runs with complete API and libraries on far, far more platforms than.Net (complete API and libraries).
Mono and dotGNU are NOT complete implementations of.Net
Slashdot Mirror
I agree with your strategy, but I would suggest changes to your suggested frameworks:
Don't use Hibernate, use JDO (Java Data Objects). Hibernate is a great product, but it's single-vendor and a proprietary API. JDO is a standard, with 30 competing vendors, some open-source, and is better designed to cope with larger systems.
Don't use Struts (or just Struts), use JSF(Java Server Faces). This transition is recommended by the creator of Struts. JSF is much simpler to code for, and is a standard API that is being widely accepted by different vendors (you can include free JSF components from, say, Sun and Oracle in the same application). There are visual form designers to speed development.
If you are developing large projects, it makes sense to develop to standards that allow you to switch between competing (possibly commercial) products.
I am beginning to suspect that Intel does things like this simply to make x86's instruction set harder and harder to emulate well.
Why should this have anything to do with the instruction set? The principle is exactly the same as for existing multi-processor systems, but on the same chip.
Just curious, but how is PHP better in code gluing?
I thought Java's inherit OOP design would make it easier to integrate code, whereas PHP only recently supported "real" OOP in PHP5.
I have recently discovered the Spring system for Java (www.springframework.org) It is a huge system, but you need only use the parts you need. I use the it as a way of managing settings for my applications (to avoid having to load in lots of properties files) and to glue parts of the my code together. It's very easy to use for this.
While your experiences with PHP may have limited it to small environments, ours proves PHP can scale quite easily.
I didn't mean that it would not scale in terms of bandwidth (although my feeling is that with servlet/JSP, where you end up with hotspot-optimised native code, is always going to be faster than interpreted PHP), but I would suggest that PHP does not always scale well in terms of application size. It sounds like that is not relevant to you.
I think one thing we can agree on is that it's all based on the code behind the scenes, no matter what the environment.
Absolutely.
PHP is straightforward and easy, and most distributions have their own packages for it. Whereas with Java, the initial set up is overwhelming for beginners.
Interesting. I have found the exact opposite: it can be a real struggle to uninstall the default (minimal) installations of apache and PHP from many distros, in order to recompile and re-install these packages to allow anything but the simplest PHP applications to run.
On the other hand, Java is a simple RPM, and tomcat is just a gzip/untar...
Yeah, then spend 6 hours wrestling with mod_jk so it will play nice behind Apache.
Or just use simple redirects (a few lines in httpd.conf).
Its either that or use Tomcat to serve your static files, which is silly, if you have any traffic.
Why? Tomcat + Java is fast. Not as fast as Apache alone, true. But anyway, the answer is simple: put static content in a directory which is not subject to a redirect to Tomcat.
You don't need to use Apache at all - doing so is only a matter of convenience or preference. My point was about what you have to do to get PHP working (at least on some distros). There is a big difference.
Tomcat could be the best software on the face of the Earth, with the easiest install ever devised. Unfortunately we quit using Tomcat over two years ago after we saw it running 100 threads and using 1GB of memory (with a Java imposed memory limit in place). Not even Oracle uses that much memory, and this is just a webserver we're talking about. Nobody could come up with a single argument not to give it the axe, so away it went.
There are two reasons why this can happen: Naively written java code (JSPs or Servlets) can bring data in and store it in session-scope rather than request-scope. As sessions can last for a long time (say, 30 minutes), you soon end up with lots of memory use (been there, done that!). The other reason is inappropriate configuration of the Java VM and tomcat. The maximum number of threads is a single setting in the server.xml file - easy to change. If you are only doing minor work in each request, turn down the memory allocation: this can be set using JAVA_OPTS.
Having a large number of threads should not be an issue - the Java VM is designed to handle this easily.
The argument for not giving it the axe is plain (in my opinion): Code carefully, and tomcat/J2EE will give you very scalable applications - not just in terms of the number of users, but to allow for significant expansion of the code size.
However, if you are really only adding minor code to web pages, PHP will do fine.
Yup, because it is a *LOT* harder to install, and administer. It's all scary black magic, and down right confusing.
Er. Download tomcat. gunzip and untar. place JAVA_HOME into catalina.sh. Set a manager account in the config file. Start it up. It's one of the easiest installs I have ever done.
Installing, starting, and stopping individual web apps is all done with a simple web interface. It's one of the easiest systems to administrate I have used.
Compare to PHP, where on some Linux distros the only way to get it working is to compile it yourself, along with specific versions of apache.
Tomcat also has the advantage that its trivially simple to run everything as non-root, for security: You just untar it into a user account and start it there!
Is this really a major climate change or just part of the normal variation in weather. We don't know. Why? We don't have enough data yet. Even in places like London, accurate weather records stretch back less than 200 years. Records of global weather are only a few decades old.
Not quite - this is true for accurate records, but we have broad knowledge of a far longer period. The last millenium has been unusually stable. Even a slight change in climate, even for a short while, would be disastrous if we don't prepare for it. Climate is going to change dramatically sometime soon anyway, as part of natural processes, whether we minimise human influence or not.
Even normal variations in climate could threaten millions of lives - after all, the normal climate over the past few million years is ice age.
So relax, the chances of anything like this happening in your lifetime is vanishingly small.
Too late. The climate change is already under way. Increased heat waves in Europe, increased hurricane frequency, thinning of ice caps, retreating glaciers. Whether or not this is due to human activity, its happening. Now.
Glaciers, for those who haven't guessed, don't sit in neutral...so unless its an ice age, they are gonna be retreating.
How do you work this out? Of course glaciers can sit in 'neutral'. They may grow a few metres one year, and shrink back another year, but on average stay that same.
The point of XML isnt that its human readable.
Well, that was one of the design considerations. The point being that XML data should be meaningful even if you don't have the software to read it.
And, for those who want something more cross-platform and established: COBOL on the JVM:
http://www.legacyj.com/lgcyj_perc1.html
You can obfuscate XML content just as easily as you do with binary structures, while still having a perfectly valid XML document.
So what?
With XML you have to put work into obfuscating it, and you have the possibility of having a clear and reasonably self-documenting format.
With binary formats its already obfuscated from the start. If I hand someone a binary file, were is the built-in indication of endian-ness, work length, data labelling or structure?
Other components like Windows.Forms, Directory.Services, Enterprise Services and JScript are being developed but are not as mature as the other components but are under development by various people.
.Net is being used for. But, a large number of developers (perhaps the majority) develop server-side, and stable enterprise APIs are important to at least some of us. It's neither practical or sensible to start developing with Mono hoping that certain parts of the enterprise features will be stable and complete sometime soon (especially when their website gives contradictory information). The choice for stable enterprise features is currently between Microsoft .Net or J2EE. If you want portability, it has to be J2EE.
Yes, I have seen that page. It's the same page that mentions that some of the enterprise services are likely to remain unsupported!
That page gives a definite emphasis on the intended use of Mono: the 'open source desktop'. Well, fine! That's actually what a lot of
Both of these quotes appear to be out of context, i'm not even sure where the first one comes from and the second one is in respect to running VisualStudio.NET programs under the current version of mono.
h tm l
They are not out of context. They are taken directly from the Mono roadmap page:
http://www.mono-project.com/about/mono-roadmap.
The second is not in respect to VisualStudio.Net programs. Its a general statement. VisualStudio.Net is not mentioned in that context at all.
when mono 2.0 is finished, you should be able to run anything not depending on something in the Microsoft.* namespace.
This is contradicted by the Mono website!
I quote:
Although WinFS, Avalon and Indigo are very exciting components, at this time it is too early to tell when those components will be available for Mono.
and:
Unsupported technologies
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.
System.EnterpriseServices and System.Management come to mind, and we are unlikely to put any resources into the task. We would gladly host the code if someone cares to implement it, but they would likely remain unsupported features of Mono.
According to Microsoft, System.EnterpriseServices
"provides an important infrastructure for enterprise applications" and System.Management "allow management software to diagnose and correct problems in an enterprise computing environment".
This functionality is NOT absent in J2EE implementations. Namespaces such as javax.management are available in all J2EE app servers, including JBoss, the open source implementation.
And I can certainly respect your point about porting legacy systems to new technologies being a pain, but hey, it gives you a job (hehe).
heh - and a lot of others too!
I guess what chaps me the most about everybodies anti MS sediments is the fact that MS DOES provide good technologies, but nobody ever gives them the credit.
I agree that when they do things, they do things well. My grouch with them is based on nearly 30 years (!) of using their products (I used their cassette-tape-based Macro Assembler for Z80 in the 70s). They always seem to play catch-up with other technologies then act as if they invented them! From Windowing to Object Orientation. I remember a recent note on their website regarding the addition of inheritance to Visual Basic in VB.Net as 'Innovative'! Excuse me! I was using inheritance in Smalltalk 20 years ago! They could easily have added full object-orientation to Visual Basic a decade before and made things easier for developers, but chose not to, for marketing reasons. Its their combination of arrogance and nerve that gets to me.
Ok, you see like a reasonable fellow compared to the normal slashdork fangirls we see around here so I had a knee-jerk reaction to you and apologize.
That is very decent of you - thanks!
It's not that Java is bad. It's that Sun's stewardship of Java has been bad. All the way from McNealy screaming in the late 90s that Java was the platform and the OS was irrelevant to the disaster that is Swing.
I certainly agree with you in most respects here. Sun have never been good at knowing how to pitch Java. It should never have been released when it was, when it was slow and buggy.
Swing was absolutely a disaster when it was released - I simply couldn't believe people would write applications that had an interface so slow! Now it is vastly better, with the ability to use OpenGL acceleration. I think you can now write very reasonable applications in Swing, but it has taken a long time to get there!
As for J2EE: There are good bits and bad bits. The bad bits are the enterprise Java beans - cumbersome and hard to debug. The good bits (I think) are the JSP/Servlet parts, and the message queue features.
My personal like of Java is that no matter how bad Sun's implementation of things, you have a choice: if you don't like parts of J2EE, use replacements for it such as Spring.
The only missing bits are going to be the Microsoft.* namespace. This is insignificant.
If this is going to be the case soon, I'm certainly going to be more interested in Mono, although I'd still be very nervous about what MS would do if Mono got really successful.
Oh really? What kind of support? I'm somehow entitled to talk to a support engineer from Sun because I download the SDK? Or are you talking abut a support contract?
Support contract. You can buy support for Java from Sun.
And how old is mono? mono is just starting up, their goal isnt even to get api compatibility untill 2.0
.Net.
A good reason to hold off using it for large-scale and business critical applications.
and people are running mono in production environments with xsp already.
Yes, but this STILL does not answer my point about incomplete APIs. I wish Mono well, and hope it takes off as a popular and successful development platform: an open-source and robust competitor to Java would be a great idea. But, it should stand on its own - and not try to be what it can never be - a full cross-platform implementation of Microsoft
but just as much as Java has failed with "write once run anywhere
.NET will be dropped and they will release somthing new, but that's fine,
I think that almost all current Java developers would disagree with you here! Almost all the tools I use for Java development and all the libraries I use are completely platform neutral. In the early days there were serious platform-dependencies (there were thread issues on Linux for example), but those days are long past. I routinely transfer major projects between Windows, Solaris and Linux with no effort at all.
Eventually way downt he road
Those of us (like me) who spend a significant part of their time struggling to port legacy code to something modern and supportable learn to worry about such dropping of technologies. Java, for all its many faults, has been designed to be around for decades.
Can anybody admit though that virtually everything in the Java 1.5 release was just catching up to where C# is now?
I won't agree! There are huge new features in Java 1.5 with have nothing to do with C# - additions to the threading libraries, GUI enhancements etc. Generics have been under development for a very long time in Java (before C#) and are done in a different way. Annotations are, I agree, a catch-up feature (and very welcome).
however the only concern i believe is that in case of an accident there could be a terrible disaster before the reaction becomes stable. ofcourse its a remote possibility, though...
The really good thing about fusion reactors as against fission is that they are very safe, and won't cause disasters. The amount of energy contained in the reactor at any instant is small (especially compared with all the energy in the core of a fisson system!). If anything goes wrong with a fusion reactor, bits of it burn out and it needs some repair, and that's all.
Name five platforms that J2EE has been ported to.
Windows, Linux, Solaris, HP/UX, zOS, OS/390, MacOS/X, OpenVMS, NonStop, Tru64.
Name five platforms that Mono runs on.
Well, it's available as packages for Linux, Windows, and MacOS/X. I would imagine that it would compile for many other platforms, such as Solaris and BSDs (that's 5!). I would be surprised to see a version for OpenVMS or zOS.
This comparison is irrelevant anyway - it's not answering my point about incomplete APIs in Mono.
Oh, I understand how bitter you and the other rabid microsoft haters are that Mono and dotGNU was even started.
.Net: significant bits are missing, and are always likely to be.
.Net. So what? This is of no relevance to the discussion at all. Java (all implementations) runs with complete API and libraries on far, far more platforms than .Net (complete API and libraries).
.Net
Not bitter, just puzzled. Why copy Microsoft? All that expertise could have gone into an entirely new bytecode/runtime/language combination - something that could never be threatened by patents or trying to catch a moving target.
I find it bizarre that so many developers who don't like Java (because of licencing) are prepared to work on duplicating Microsoft technologies. In the past, anyone who has come anywhere developing a successful clone of a Microsoft product as either been sued or bought out. That is not an emotional response, or Microsoft-hating, its all on the record.
And the most infuriating thing for the linux fangirls is that many Gnome developers actually like Mono/Gtk#.
Why should it be infuriating? Mono/Gtk# is a great technology, and has come far in a short time. Good luck to it! It would be great if Mono became a high-quality standard for cross-platform enterprise applications. Guess what! It runs Java too!
My point is that it is NOT
It looks like you've drunk the Sun koolaid regarding cross-platform. dotGNU already runs on more platforms than any Sun implementation of Java.
How is this relevant to anything? The Sun implementation of Java runs on far more platforms than the Microsoft implementation of
Mono and dotGNU are NOT complete implementations of
And finally, when did Sun support the JDK?
Like, since 1994 when Java was released.