If you've done any medical software, you'd know you're forced to reveal algorithms there, too.
Applying for the patent in fact _forces_ you to reveal the algorithm to the entire world. That's the entire point of the patent process. You reveal it to the world instead of hiding it, and as a result you get exclusivity for a period of time. If you don't want to reveal it, you have no leg to stand on if someone else manages to also invent it. There are very good historical reasons for this system, the most significant of one was that it was felt to be in the *public's* best interest for inventors to reveal their ways and means, and thereby fuel more innovation in the same area. Virtuous circle and all that rot, roight?
Now, 14 year software patents are a little more powerful than 14 year drug patents, of which half the term is expired before you even manage to get the drug to market. There's probably room to tweak the system a bit for software. But fundamentally the system does what it's designed to do.
I work in a datacenter, for a company that has thousands and thousands of blades in our infrastructure. We primarily use HP blades, either the BL25p or the BL35p. One limitation of the BL35p is that the default configuration is SATA drives. The BL25p comes with SCSI.
The difference is very stark, in terms of drive failures. We have a seriously disproportionate number of SATA drives fail, to the point where we simply aren't buying BL35p's anymore with SATA, they're just not worth the extra hassle from drive failures.
They deliberately stuck with the case designs going from PowerPC to Intel. Notice every single product has had exactly the same case -- the iMac, the Mini, the Powerbook / MB Pro, and now the desktop and rackmount lines. Do you really think this is an accident? This _is_ Apple we're talking about here.
So the question to ask yourself is, why would they stick with those designs in such a deliberate fashion?
The stated answer from people inside Apple is that market research showed consumers would more easily accept the transition to Intel if the boxes themselves stayed the same. So you're looking at a two-phase upgrade path -- first the internal components, then the external shell. Next year you can expect at least a couple case upgrades, if not all of them. The likely scenarios are:
* Mini transitions into some sort of home electronics-friendly look&feel, to put in your living room
* MacPro cheese-grater gets thrown away for something significantly smaller, now that they don't need to dissipate so much heat. No way will they simply downsize the current model, either, it'll change significantly.
* Macbook Pro is due for some changes, although I have to say that since I've a 15" version in both the PowerPC and Intel versions of this, that it's hard to see what they can improve. The most significant thing they could do for me would be to add a second mouse button -- which of course people will say "OMG ABOUT TIME"... Other nice things -- maybe make it so the case itself doesn't get so damn hot. And trim 2 lbs off it, but I don't see how.
* I have trouble imagining what the next iMac will look like, but somehow I don't think Apple has the same problem.
The one model I don't think will change is the XServe. It's just fine like it is, so other than technology updates I doubt they'll mess with it. Plus, just how much can you do with a 1U rack mount server anyway?
I have Speakeasy as well. I bought a 1.5M down, 768K up DSL line initially. Later they started selling 6M down, and I upgraded to that. My line was a little unstable, probably due to older wiring in the building, and we lowered the speed to 4Mbps in order to keep it stable. They were apologetic at not being able to give me the full 6Mbps, and knocked a portion off my monthly to compensate.
Every time I call the service is fast and efficient. Yesterday I needed another static IP assigned, and it took literally 60s to do with the first tech I got on the phone. The guy obviously knew his stuff, despite being tier 1 tech support for them.
Basically I can't recommend them highly enough. You get what you pay for.
Actually, as you said, VRML is/was a modelling language. How it gets rendered (and whether or not that rendering supports stereoscopic devices) is completely up to the 'player'. So VRML (or X3D) can be real 3D by your standards, and in fact back when I worked with VRML there was support for viewing it in stereo on the usual suspect's hardware (Crystal Eyes or whatever it's called, it's been a while).
They're absolutely gaming quality. I play World of Warcraft, and my new MBP is _lots_ faster than my dual proc G5. I do 40 person raids most of the time I'm online, and the MBP handles them just fine. Compared to my PC desktop running Windows XP it's not as fast, but that system is an AMD 4800+ and a 7800 GT OC.
Notably, I got the 7200 RPM drive on the MBP, maxed out the RAM, and of course am using the 2.16GHz processor.
Almost every Unix/clone is continually posting security patches to prevent exploits that are available once you have a shell (some of the BSDs are relatively hard to hack, that's it). This has been a problem for decades now. Shell = cracked, and you'll be lucky to last 30 minutes if you're giving away shell accounts on a new Linux install. The only reason MacOS would have lasted 30 minutes is because it's probably the first time anyone bothered...
As far as this making MacOS unsuitable for servers goes:
1) Most servers *I* run have extremely limited access rights, so this wouldn't be a problem, except:
2) MacOS throughput is pitiful due to a threading implementation aimed more at desktop users. Until they come out with a Server product that can get within 90% of Linux and/or Windows, serving stuff on MacOS will be a very expensive proposition anyway. You basically need twice as much hardware to get the same # of concurrent users.
So, why don't we hear about the folks who won first place? How much do you want to bet that they used some super high tech ceramic that simply doesn't break when dropped from 9'? Of course, that wouldn't be nearly as 'interesting' as that other monstrosity...
Reading the Dvorak piece, you're right, he's on crack!
I guess he doesn't realize just how many people buy Macs specifically because of the OS. He says they'd like to compete on "even ground" with Dell, Sony, etc -- when in fact the OS gives him a high ground to fight from. If Macs shipped with Windows, I bet at least half their current userbase would go from being grudgingly accepting of the steep premium you pay for their hardware to being rightly pissed off. The hardware isn't _that_ much better than what you can buy in the Windows world. Why would I continue to pay 30-50% more and what would I be getting that justified that, and is it something that would be compelling for IT purchasing? Somehow I don't think so.
I say this as someone who has spent over $20K on Apple hardware out of my own pocket in the last 5 years. If Apple shipped with Windows instead of MacOS, that number would be closer to $2K (ie, just the iPods).
(Let's see if I remember to hit the plaintext format pulldown this time...)
JSF is not what I would consider a RAD framework for the web. If you use the right development tools, I suppose it could be, in that the 'right' JSF development tool will generate a lot of configuration for you automatically. However, it will still leave you a fair amount to do in terms of writing controllers and data binding. I can _imagine_ a tool which could replicate what Rails does by making intelligent choices for all the libraries you need and auto-generate the code and configuration required to hook it all together. But nothing like that tool exists. Some folks do seem to be trying to get there (Seam being one of them, sorry for the pun).
That said, there are some folks trying to replicate what Rails does for Ruby, in Java. There's also AppFuse, which is a bit more of a Java-centric way to do RAD. Of course, Ruby is a more dynamic language than Java, so you end up doing a lot more code generation and a lot less configuration by convention. That's not necessarily a bad thing, just different.
Rails (not Ruby) is faster than Java because it's a RAD framework. R = Rapid. If you used a Java RAD framework (there are a couple), it'd be just as fast. Ruby _can_ be faster (to develop) than Java due to things like collections semantics, but there's no guarantee it will be.
As far as MVC separation goes, the two languages are functionally equivalent with the right framework. People conflate Rails with Ruby, but that's a mistake. Java was popular long before any great web frameworks existed for it, but now that they're there, people don't conflate WebWork (for instance) with Java. They do with Rails and Ruby because the two are getting popular together.
With Rails, you have.rhtml files as your view, with scripting possibilities available there. You have your controller obviously, and your model bound to a db via ActiveRecord. This is no different from something like WebWork where you have a.jsp file as your view with JSTL scripting available within it, a controller class that provides objects to the view to manipulate, and model objects that use Hibernate to bind to a db.
Ruby will get additional libraries and third party support over time. Heck, it may even get another web dev framework besides Rails (would be nice, people might quit conflating them). So I think over time Ruby will become a more compelling replacement for Java, and of course people who like to do original development for the sake of getting their name out there or just pride have a lot more to do in Ruby than they do in Java. That's true for books too, imagine trying to write a Java book today covering almost any topic, it's guaranteed to be a "me too" book. But with Ruby you can be the first guy to write the classic ActiveRecord book, or whatever it is you become an expert in. So yeah, it doesn't surprise me that people who create libraries or right books are excited about Ruby, there's more left to do. But that doesn't mean I'm gonna start using it in production code.:)
Some products take a lot longer to purchase than an iPod does. For instance, if you're buying a new G5 or Cinema Display, they don't just have piles of em sitting at the register waiting for you to show up. On the other hand, the iPod lines _did_ have just that, and I'm sure the people buying iPods (all 10 bazillion of you) appreciated the courtesy of not having to wait for a customer to get their G5 moved from the back storeroom before you make your 6 oz purchase.
Other stores I've dealt with which have this problem (e.g., IKEA) seem to have a two-step process where step 1 is that you make your purchase and receive a claims slip of some sort. You then take the claims slip to a shipping/receiving type department which fulfills your order. I've been to 4 or 5 Apple Stores in the Bay Area, and none of them have the kind of room you'd need to set this up. They tend to be fairly light density for retail space as it is, and trying to add an area for dealing with bulky merchandise post-purchase would probably kill space they're using for something else major, like software, the Genius Bar (great service!) or like the one in SF, a mini-theatre with live presentations of various software products running on MacOS X.
Wait, a major db-driven web app and you're complaining about Swing and memory usage? Java is perfectly fine for db-driven web apps. In fact, I'd say of the three you mentioned, it has the richest set of frameworks you can use to build your app with.
Java memory usage on the server is nothing special -- either direction. And you never touch Swing when you're writing server code, so I don't get why you're ruling it out.
If you were writing a client app, sure, you have to need certain things to make Java the right choice. It has to need to run on multiple platforms, but look native on each of those platforms, without wanting to go the big $$ approach of writing multiple UI adaptation layers in C++. Java is actually the best at that, but that's a pretty specific set of constraints. I'd probably just write a C library and do it in.Net on Windows and ObjC on MacOS and call it a day, and if someone wanted to port it to Linux, great, go for it.
But for a webapp? Unless it's something you're only putting 1 or 2 developers on, which hardly qualifies as "major", Java is the best choice IMO. Often it's the best choice even for small projects, although RoR / PHP / Python look a lot stronger at that point.
How about it's seeming inability to parse the EL in WebSphere 6? And its JSP implementation seems non-standard as well, stuff that parses fine in every other JSP implementation I've used pukes in WebSphere.
We're obviously both entitled to our opinions, but its nonstandard configuration and incomplete JSTL support alone are enough for me to cross it off my list of app servers I'd most like to go out with.
At the risk of sounding defensive, this guy is so dumb that even when he's right, he's wrong.;)
1) He completely misses the biggest challenge to Java right now, Ruby. Probably because it doesn't fit nicely into the LAMP acronym.;)
2) AJAX and Java are orthogonal, tons of AJAX stuff is being written in Java, all of the major frameworks except Struts have an AJAX project now.
3) Him mentioning Google using AJAX as if it's a sign that Java is dying is one of the more amusing misconceptions. Google originally was a Python shop primarily, but they simply couldn't find enough developers, so now they're the fastest hiring Java shop on the planet. They probably have as many Java programmers as Sun does at this point.
4) Websphere as an indicator of Java's success?? Puhlease, people are finally waking up to the fact that Websphere _sucks_ is all that is.
5).Net on the desktop is nominally competing with Java, but not really. MS is competing with itself there, and most of the.Net uptake is from people who are moving from unmanaged C++ to managed C# or from VB to VB.Net. Not really a Java story at all, I'm pretty sure.Net growth for web applications has been flat for the last couple years, going by job postings and book sales. Of course, he's right that.Net has killed most of the failing momentum that Java on the client had, and at this point you'd have to very carefully evaluate whether or not to do Java there. It's kind of a needle you have to thread to justify it IMO, you need to have high cross-platform requirements combined with high usability requirements, and yet not be able to do the whole thing in the browser, which AJAX makes more usable than ever. That may be the only way in which AJAX and Java compete, there are client-side Java applications that aren't being written now because of AJAX. Of course the developers are using Java on the server to do it.;)
6) 0 PHP websites in 2000? Heh, PHP 3 came out in 1998 and was the first big uptick in adoption. Maybe he means there were 0 PHP 4 websites in 2000, except that'd be wrong too, since PHP 4 was released in early 2000. My first PHP project was in 1999, personally, and I was late to the party.
7) The Merrill's of the world don't use Java as much and likely never will, it's true. I like how they're just using Linux and Apache, though. I wonder what this guy thinks they're doing, static websites? Of course, based on the quote we know what he meant to say, which is that C and C++ on the server still have a following where things have to be highly scalable and still achieve close to real-time performance. Despite that, the financial services sector is still a big source of Java jobs, and those jobs aren't going to be lost to Perl or PHP coders anytime soon.
Over all, going by job postings, Java is actually significantly up since 2000, but down a little since 2003 I'd say. The main culprit is the LAMP stack, although it's not Perl that's the real problem, it's Ruby and PHP. And the entire focus on languages is misguided, adoption follows the frameworks, not the languages. Java on the server was the proverbial red-headed stepchild until J2EE was released. 90% of the uptick in Ruby development is because of the most excellent Rails framework, which makes it dead easy to knock out a simple CRUD application.
Thing is, the Ruby/Rails and PHP folks have a long way to go before they're going to be a solution you can use in corporate environments. They're perfect for homebrew web applications where you have 1 or 2 developers and the development team also controls the data model. Throw in any legacy data, or a team size greater than roughly 5 developers, and the framework breaks down fast. These people are still debating that you shouldn't put constraints in the db, something that enterprise developers the world over would laugh their asses off at.;)
No offense, but which would you rather have, standards that outpace implementation, or implementations that help define standards?
You can't have both, there's no free lunch here, and the fact is that standards implemented in a vacuum have had significantly less success than standards which follow actual implementations (OSI anyone?)...
I have nothing against calling a spade a spade, Microsoft's business practices leave a lot to be desired. But you can't knock them or anyone else for trying to innovate in their implementations. It's those innovations that help pave the way for the standards you obviously appreciate. Once the innovations show up, content developers take advantage of them, and help further the case that the standards bodies should take a look at how to add this to Web++...
sulam> I didn't say "old", I said "older." English, whadda language!
MFN> No, you said "older". Go re-read:
Violent agreement? I said I said "older". You quote me saying I said "older." What am I supposed to be disagreeing with? Why are you telling me what I said?;)
I assume you're referring to destructors, which Java has as well. However, they often aren't used because any exceptions thrown in them (in either language) have the potential to leave you in a bad state with the resource leaked anyway.
Easy answer, don't run Netbeans. And your statement that 1.5 is not that different from 1.4 is completely incorrect. In 1.4 and before, the JVM made assumptions that were appropriate for client-side apps despite the fact that most of the Java code in the world runs on the server. In 1.5 the defaults got changed to something that makes sense for servers.
For most server-side apps, db or network performance are the primary bottlenecks -- not the middleware.
If you run a non-incremental garbage collection routine, and you completely fill up your old generation, yes you can have this happen. However, the default is incremental collection, which will never cause the behavior you describe.
Your knowledge of GC is as out of date as your knowledge of Java performance.
Slashdot Mirror
If you've done any medical software, you'd know you're forced to reveal algorithms there, too.
Applying for the patent in fact _forces_ you to reveal the algorithm to the entire world. That's the entire point of the patent process. You reveal it to the world instead of hiding it, and as a result you get exclusivity for a period of time. If you don't want to reveal it, you have no leg to stand on if someone else manages to also invent it. There are very good historical reasons for this system, the most significant of one was that it was felt to be in the *public's* best interest for inventors to reveal their ways and means, and thereby fuel more innovation in the same area. Virtuous circle and all that rot, roight?
Now, 14 year software patents are a little more powerful than 14 year drug patents, of which half the term is expired before you even manage to get the drug to market. There's probably room to tweak the system a bit for software. But fundamentally the system does what it's designed to do.
I work in a datacenter, for a company that has thousands and thousands of blades in our infrastructure. We primarily use HP blades, either the BL25p or the BL35p. One limitation of the BL35p is that the default configuration is SATA drives. The BL25p comes with SCSI.
The difference is very stark, in terms of drive failures. We have a seriously disproportionate number of SATA drives fail, to the point where we simply aren't buying BL35p's anymore with SATA, they're just not worth the extra hassle from drive failures.
They deliberately stuck with the case designs going from PowerPC to Intel. Notice every single product has had exactly the same case -- the iMac, the Mini, the Powerbook / MB Pro, and now the desktop and rackmount lines. Do you really think this is an accident? This _is_ Apple we're talking about here.
So the question to ask yourself is, why would they stick with those designs in such a deliberate fashion?
The stated answer from people inside Apple is that market research showed consumers would more easily accept the transition to Intel if the boxes themselves stayed the same. So you're looking at a two-phase upgrade path -- first the internal components, then the external shell. Next year you can expect at least a couple case upgrades, if not all of them. The likely scenarios are:
* Mini transitions into some sort of home electronics-friendly look&feel, to put in your living room
* MacPro cheese-grater gets thrown away for something significantly smaller, now that they don't need to dissipate so much heat. No way will they simply downsize the current model, either, it'll change significantly.
* Macbook Pro is due for some changes, although I have to say that since I've a 15" version in both the PowerPC and Intel versions of this, that it's hard to see what they can improve. The most significant thing they could do for me would be to add a second mouse button -- which of course people will say "OMG ABOUT TIME"... Other nice things -- maybe make it so the case itself doesn't get so damn hot. And trim 2 lbs off it, but I don't see how.
* I have trouble imagining what the next iMac will look like, but somehow I don't think Apple has the same problem.
The one model I don't think will change is the XServe. It's just fine like it is, so other than technology updates I doubt they'll mess with it. Plus, just how much can you do with a 1U rack mount server anyway?
They can't?? Don't you mean they shouldn't? Because they sure have! ;)
I have Speakeasy as well. I bought a 1.5M down, 768K up DSL line initially. Later they started selling 6M down, and I upgraded to that. My line was a little unstable, probably due to older wiring in the building, and we lowered the speed to 4Mbps in order to keep it stable. They were apologetic at not being able to give me the full 6Mbps, and knocked a portion off my monthly to compensate.
Every time I call the service is fast and efficient. Yesterday I needed another static IP assigned, and it took literally 60s to do with the first tech I got on the phone. The guy obviously knew his stuff, despite being tier 1 tech support for them.
Basically I can't recommend them highly enough. You get what you pay for.
Actually, as you said, VRML is/was a modelling language. How it gets rendered (and whether or not that rendering supports stereoscopic devices) is completely up to the 'player'. So VRML (or X3D) can be real 3D by your standards, and in fact back when I worked with VRML there was support for viewing it in stereo on the usual suspect's hardware (Crystal Eyes or whatever it's called, it's been a while).
They're absolutely gaming quality. I play World of Warcraft, and my new MBP is _lots_ faster than my dual proc G5. I do 40 person raids most of the time I'm online, and the MBP handles them just fine. Compared to my PC desktop running Windows XP it's not as fast, but that system is an AMD 4800+ and a 7800 GT OC.
Notably, I got the 7200 RPM drive on the MBP, maxed out the RAM, and of course am using the 2.16GHz processor.
Almost every Unix/clone is continually posting security patches to prevent exploits that are available once you have a shell (some of the BSDs are relatively hard to hack, that's it). This has been a problem for decades now. Shell = cracked, and you'll be lucky to last 30 minutes if you're giving away shell accounts on a new Linux install. The only reason MacOS would have lasted 30 minutes is because it's probably the first time anyone bothered...
As far as this making MacOS unsuitable for servers goes:
1) Most servers *I* run have extremely limited access rights, so this wouldn't be a problem, except:
2) MacOS throughput is pitiful due to a threading implementation aimed more at desktop users. Until they come out with a Server product that can get within 90% of Linux and/or Windows, serving stuff on MacOS will be a very expensive proposition anyway. You basically need twice as much hardware to get the same # of concurrent users.
So, why don't we hear about the folks who won first place? How much do you want to bet that they used some super high tech ceramic that simply doesn't break when dropped from 9'? Of course, that wouldn't be nearly as 'interesting' as that other monstrosity...
Reading the Dvorak piece, you're right, he's on crack!
I guess he doesn't realize just how many people buy Macs specifically because of the OS. He says they'd like to compete on "even ground" with Dell, Sony, etc -- when in fact the OS gives him a high ground to fight from. If Macs shipped with Windows, I bet at least half their current userbase would go from being grudgingly accepting of the steep premium you pay for their hardware to being rightly pissed off. The hardware isn't _that_ much better than what you can buy in the Windows world. Why would I continue to pay 30-50% more and what would I be getting that justified that, and is it something that would be compelling for IT purchasing? Somehow I don't think so.
I say this as someone who has spent over $20K on Apple hardware out of my own pocket in the last 5 years. If Apple shipped with Windows instead of MacOS, that number would be closer to $2K (ie, just the iPods).
(Let's see if I remember to hit the plaintext format pulldown this time...)
JSF is not what I would consider a RAD framework for the web. If you use the right development tools, I suppose it could be, in that the 'right' JSF development tool will generate a lot of configuration for you automatically. However, it will still leave you a fair amount to do in terms of writing controllers and data binding. I can _imagine_ a tool which could replicate what Rails does by making intelligent choices for all the libraries you need and auto-generate the code and configuration required to hook it all together. But nothing like that tool exists. Some folks do seem to be trying to get there (Seam being one of them, sorry for the pun).
That said, there are some folks trying to replicate what Rails does for Ruby, in Java. There's also AppFuse, which is a bit more of a Java-centric way to do RAD. Of course, Ruby is a more dynamic language than Java, so you end up doing a lot more code generation and a lot less configuration by convention. That's not necessarily a bad thing, just different.
Wewps, apparently I forgot to hit plaintext format...
Rails (not Ruby) is faster than Java because it's a RAD framework. R = Rapid. If you used a Java RAD framework (there are a couple), it'd be just as fast. Ruby _can_ be faster (to develop) than Java due to things like collections semantics, but there's no guarantee it will be. As far as MVC separation goes, the two languages are functionally equivalent with the right framework. People conflate Rails with Ruby, but that's a mistake. Java was popular long before any great web frameworks existed for it, but now that they're there, people don't conflate WebWork (for instance) with Java. They do with Rails and Ruby because the two are getting popular together. With Rails, you have .rhtml files as your view, with scripting possibilities available there. You have your controller obviously, and your model bound to a db via ActiveRecord. This is no different from something like WebWork where you have a .jsp file as your view with JSTL scripting available within it, a controller class that provides objects to the view to manipulate, and model objects that use Hibernate to bind to a db.
Ruby will get additional libraries and third party support over time. Heck, it may even get another web dev framework besides Rails (would be nice, people might quit conflating them). So I think over time Ruby will become a more compelling replacement for Java, and of course people who like to do original development for the sake of getting their name out there or just pride have a lot more to do in Ruby than they do in Java. That's true for books too, imagine trying to write a Java book today covering almost any topic, it's guaranteed to be a "me too" book. But with Ruby you can be the first guy to write the classic ActiveRecord book, or whatever it is you become an expert in. So yeah, it doesn't surprise me that people who create libraries or right books are excited about Ruby, there's more left to do. But that doesn't mean I'm gonna start using it in production code. :)
Some products take a lot longer to purchase than an iPod does. For instance, if you're buying a new G5 or Cinema Display, they don't just have piles of em sitting at the register waiting for you to show up. On the other hand, the iPod lines _did_ have just that, and I'm sure the people buying iPods (all 10 bazillion of you) appreciated the courtesy of not having to wait for a customer to get their G5 moved from the back storeroom before you make your 6 oz purchase.
Other stores I've dealt with which have this problem (e.g., IKEA) seem to have a two-step process where step 1 is that you make your purchase and receive a claims slip of some sort. You then take the claims slip to a shipping/receiving type department which fulfills your order. I've been to 4 or 5 Apple Stores in the Bay Area, and none of them have the kind of room you'd need to set this up. They tend to be fairly light density for retail space as it is, and trying to add an area for dealing with bulky merchandise post-purchase would probably kill space they're using for something else major, like software, the Genius Bar (great service!) or like the one in SF, a mini-theatre with live presentations of various software products running on MacOS X.
Wait, a major db-driven web app and you're complaining about Swing and memory usage? Java is perfectly fine for db-driven web apps. In fact, I'd say of the three you mentioned, it has the richest set of frameworks you can use to build your app with. Java memory usage on the server is nothing special -- either direction. And you never touch Swing when you're writing server code, so I don't get why you're ruling it out. If you were writing a client app, sure, you have to need certain things to make Java the right choice. It has to need to run on multiple platforms, but look native on each of those platforms, without wanting to go the big $$ approach of writing multiple UI adaptation layers in C++. Java is actually the best at that, but that's a pretty specific set of constraints. I'd probably just write a C library and do it in .Net on Windows and ObjC on MacOS and call it a day, and if someone wanted to port it to Linux, great, go for it.
But for a webapp? Unless it's something you're only putting 1 or 2 developers on, which hardly qualifies as "major", Java is the best choice IMO. Often it's the best choice even for small projects, although RoR / PHP / Python look a lot stronger at that point.
How about it's seeming inability to parse the EL in WebSphere 6? And its JSP implementation seems non-standard as well, stuff that parses fine in every other JSP implementation I've used pukes in WebSphere.
e lls/arcataNode01Cell/applications/Kalinda_war.ear/ deployments/Kalinda_war/Kalinda.war/WEB-INF/ibm-we b-bnd.xml
And here's a nice exploded EAR:
IBM/WebSphere/AppServer/profiles/default/config/c
Note that log files are hidden in this structure as well.
How about that redeploying requires you to run the 6-step "wizard" and redefine all your resource bindings?
I dunno, all the people I know who use WebSphere who _also_ use other J2EE containers come away hating WebSphere.
We're obviously both entitled to our opinions, but its nonstandard configuration and incomplete JSTL support alone are enough for me to cross it off my list of app servers I'd most like to go out with.
At the risk of sounding defensive, this guy is so dumb that even when he's right, he's wrong. ;)
;)
.Net on the desktop is nominally competing with Java, but not really. MS is competing with itself there, and most of the .Net uptake is from people who are moving from unmanaged C++ to managed C# or from VB to VB.Net. Not really a Java story at all, I'm pretty sure .Net growth for web applications has been flat for the last couple years, going by job postings and book sales. Of course, he's right that .Net has killed most of the failing momentum that Java on the client had, and at this point you'd have to very carefully evaluate whether or not to do Java there. It's kind of a needle you have to thread to justify it IMO, you need to have high cross-platform requirements combined with high usability requirements, and yet not be able to do the whole thing in the browser, which AJAX makes more usable than ever. That may be the only way in which AJAX and Java compete, there are client-side Java applications that aren't being written now because of AJAX. Of course the developers are using Java on the server to do it. ;)
;)
1) He completely misses the biggest challenge to Java right now, Ruby. Probably because it doesn't fit nicely into the LAMP acronym.
2) AJAX and Java are orthogonal, tons of AJAX stuff is being written in Java, all of the major frameworks except Struts have an AJAX project now.
3) Him mentioning Google using AJAX as if it's a sign that Java is dying is one of the more amusing misconceptions. Google originally was a Python shop primarily, but they simply couldn't find enough developers, so now they're the fastest hiring Java shop on the planet. They probably have as many Java programmers as Sun does at this point.
4) Websphere as an indicator of Java's success?? Puhlease, people are finally waking up to the fact that Websphere _sucks_ is all that is.
5)
6) 0 PHP websites in 2000? Heh, PHP 3 came out in 1998 and was the first big uptick in adoption. Maybe he means there were 0 PHP 4 websites in 2000, except that'd be wrong too, since PHP 4 was released in early 2000. My first PHP project was in 1999, personally, and I was late to the party.
7) The Merrill's of the world don't use Java as much and likely never will, it's true. I like how they're just using Linux and Apache, though. I wonder what this guy thinks they're doing, static websites? Of course, based on the quote we know what he meant to say, which is that C and C++ on the server still have a following where things have to be highly scalable and still achieve close to real-time performance. Despite that, the financial services sector is still a big source of Java jobs, and those jobs aren't going to be lost to Perl or PHP coders anytime soon.
Over all, going by job postings, Java is actually significantly up since 2000, but down a little since 2003 I'd say. The main culprit is the LAMP stack, although it's not Perl that's the real problem, it's Ruby and PHP. And the entire focus on languages is misguided, adoption follows the frameworks, not the languages. Java on the server was the proverbial red-headed stepchild until J2EE was released. 90% of the uptick in Ruby development is because of the most excellent Rails framework, which makes it dead easy to knock out a simple CRUD application.
Thing is, the Ruby/Rails and PHP folks have a long way to go before they're going to be a solution you can use in corporate environments. They're perfect for homebrew web applications where you have 1 or 2 developers and the development team also controls the data model. Throw in any legacy data, or a team size greater than roughly 5 developers, and the framework breaks down fast. These people are still debating that you shouldn't put constraints in the db, something that enterprise developers the world over would laugh their asses off at.
No offense, but which would you rather have, standards that outpace implementation, or implementations that help define standards?
You can't have both, there's no free lunch here, and the fact is that standards implemented in a vacuum have had significantly less success than standards which follow actual implementations (OSI anyone?)...
I have nothing against calling a spade a spade, Microsoft's business practices leave a lot to be desired. But you can't knock them or anyone else for trying to innovate in their implementations. It's those innovations that help pave the way for the standards you obviously appreciate. Once the innovations show up, content developers take advantage of them, and help further the case that the standards bodies should take a look at how to add this to Web++...
sulam> I didn't say "old", I said "older." English, whadda language! MFN> No, you said "older". Go re-read: Violent agreement? I said I said "older". You quote me saying I said "older." What am I supposed to be disagreeing with? Why are you telling me what I said? ;)
It's certainly older than my Athlon 4800+, and it's older than G5's they sell today. I didn't say "old", I said "older." English, whadda language!
I assume you're referring to destructors, which Java has as well. However, they often aren't used because any exceptions thrown in them (in either language) have the potential to leave you in a bad state with the resource leaked anyway.
Yes, I can refute your suspicions. Incremental garbage collection algorithms exist and are used in the JVM's GC.
Easy answer, don't run Netbeans. And your statement that 1.5 is not that different from 1.4 is completely incorrect. In 1.4 and before, the JVM made assumptions that were appropriate for client-side apps despite the fact that most of the Java code in the world runs on the server. In 1.5 the defaults got changed to something that makes sense for servers. For most server-side apps, db or network performance are the primary bottlenecks -- not the middleware.
If you run a non-incremental garbage collection routine, and you completely fill up your old generation, yes you can have this happen. However, the default is incremental collection, which will never cause the behavior you describe. Your knowledge of GC is as out of date as your knowledge of Java performance.