OS/2 in 1987 was not what most people relate to as OS/2 as it was 16 bit for starters and did not have the WPS. OS/2 2.0, which was barely usable as it had extremely limited driver support so you had to buy specific hardware was released in 1990 IIRC. OS/2.1, the first version that approached real consumer usability was released in late 1990 and actually worked quite well.
And I did use many of those, and others on other hardware platforms. (Acck - admitting somewhat my age... bleah!)
I run my own business now. I get quality work done in short amounts of time, and enjoy life with all my free time. If my business went under, I think I'd have a really hard time going back to an office job. I'm spoiled rotten.
And that's why you do the intense bits of coding - 100+ hours a week for 3-4 months straight. If it's something you believe in, you can pull it off. However, everyone has their limits and they're all different. Some can only handle a few days, others months. Most drop off around 6-9 days of 12+ hours per day.
But - the real measure isn't how many hours you code, but how functional and well designed and maintainable that code is when you're done. Sometimes I wind up with less code after 12 hours than I started with, and it does more. (One of the benefits when you work for yourself is your productivity is not measured by LOCs).
Microsoft and IBM entered a lopsided contracted partnership (in MS's favor as it turned out) to build OS/2. One of MS's pieces was the filesystem. For every copy IBM sold, it was reported they owed MS $79 for the HPFS filesystem. HPFS386 was even more expensive, by another $100+ IIRC.
MS decided they could make more money faster with their own, and first release windows 95, and then NT when they had decided to break their relationship off with IBM.
Re:Not many OS/2 Apps that people are wanting
on
Is OS/2 Coming Back?
·
· Score: 1
First, Gnome reminds me a lot of PM's operation.
Regarding the OSX dock, I never use it. I much much prefer Quicksilver and the quick Cmd-[Shift]-Tab and Cmd-[Shift]-` key sets coupled with spaces.
There were also some interesting pieces in the underlying system, such as HPFS. The fact that it was inherently non-fragmenting was a source of incredible frustration for all the NTFS users.:) Then there was the actual functional TCPIP stack (also taken from BSD IIRC, like MS's, but not nerfed)
Considering I ran it for years with no issues, you were either doing something really really farfetched, or did something else that screwed up something in the OS. Oh, and when I say I ran it for years, it was my main work machine that also ran SMTP, FTP, Telnet, Gateways, and did coding and FEM modeling work, data reduction, etc. And those latter pieces were on files up to several hundred MB, so no, it wasn't idle much nor rebooted very often either - usually on the order of months. (486-66 with about 256MB of RAM and 2GB of disk space.... yes, those were the days of limited hardware resources)
I agree with Improv - OD was an awesome product that delivered on the OO promises made for WPS.
...and just not go back to Linux since there was nothing Linux did that Windows didn't.
You either have a MS world view, a peculiar use case, or just don't know what you're talking about.
Try running LDAP on Windows. Can't do that. Try running a 0 priv service that utilizes a users credentials and changes a different user's password. Can't do that without some serious gymnastics that involves using a SYSTEM or equivalent process.) Try executing a script utilizing pipes out of a daemon process (closest thing is a service in windows land) You can't.
That's just the beginning of a long long long list of things windows can't do. The list of things windows can do? It's rather short: Allow a virus/worm in under a service and wreak total havoc because there is no real concept of a lowest privilege process. Oh, and open windows office documents. Can't forget that important one.
I'll still wait a while. With a good HD the OS doesn't lag too much - my boot times are in the sub 30s range even for XP. (about 25s for POST/CD/DVD check, another 25 for the OS to come up)
If I wanted to speed that up - I'd probably add a RAID 1+0 setup and still come out ahead on pricing. (But boot times would probably be slower, since the load time saved would be spent setting up the RAID configuration.)
Since I boot once a month at most, I'll stick with cheap HDs for my desktops for now.
And what specific parameter in any Linux installation error message is likely to point towards the CPU being defective? Most of them would be generic hardware-has-shit-itself errors (DMA failures, null pointer exceptions, hash failures) that could mean any of the cpu/motherboard/ram/psu/hdd are defective. It's impossible, even in principle, for any installer to be able to pinpoint with specificity what hardware is fucked.
Well, having experienced this particular fun with a recent CentOS distribution attempting to be installed on an AMD 939 X2 CPU, the boot and install went great. Reboot into your newly installed wonderful OS? Seems ok. Login. Success! Run a couple of commands and watch the thing pull a Microsoft by falling over dead with virtually no output except for an esoteric error and memory location which was enough to pinpoint the problem. Seems our CPU release had a small piece of errata in it that prevented a certain 64-bit optimization that the CentOS kernel tried to use. Whoops.
Its really too bad that Apple never lets OS-X run in VM on non apple hardware.. then I would be in heaven!
Well, officially Apple doesn't let OSX run on non apple hardware. In reality start here and have fun.
I'm a bit of the opposite to you - I run OSX as my main OS, and run Server 2008 R2, Win 7, and Win XP in VMs (Parallels 5, VMWare 2.0 was still doing software CPUs - don't know about 3.x) and it was certainly freeing - every time windows craps out - snapshot restore and I'm back up in about 5 minutes. I've also got Linux VMs, but generally don't need to run them for testing as often as the coding I do generally transfers fluidly across and all the items I use on Linux also work on OSX.
If we had a truly free market, where there were many providers, then we'd have the mythical market you mention. In reality our version of capitalism always drives towards a monopoly.
Give me one good thing it does that's necessary, done well, and not redundant.
Um, integrate hibernate?
You apparently missed my Hibernate spiel. To sum it up - Hibernate sucks to a similar level as Spring, just in different ways.
Simplify EJBs you say? Only if you want to kill any project you're ever associated with, with or without Spring. (EJBs are one of the true Java horrors to come out of Sun, far too pretty in academic terms to ever be practical)
What I was talking isn't anything like that. It's still a conventional mocking framework in a sense that you have to set up mocks & tests yourself (though it does use some neat C# features such as expression trees to make it a lot easier than it normally is). The trick is that they use backdoors in VM to do things that you can't normally do, such as intercepting calls to constructors, non-virtual, sealed or static methods, etc, and injecting your mocks instead of what would have run. Which completely unties your hands with respect to how you design your classes, so that you can do it in a way that's actually sane in and of itself.
I think I see what you're getting at - you're asking if there's something out there for Java that would allow you to do a call to an external object in your method without actually calling it? I don't know.
I do recall looking at something a long time ago that claimed it would auto-magically walk through all your code paths and would test it externally. I still don't really see one. It would require significantly more code analysis in my opinion than anything I've seen to date.
As far as interfaces and decoupling - that's great - on component boundaries. Internally, only if needed. I've seen a "module" that had 13 layers of springified horribleness to execute a single call. I never did figure out why Spring was used, other than someone passed the kool aid around. After all, in your own component code that's making a single functional operation call, why would you need to inject 13 objects into your functional stream? Especially when there's only 1 possible instance of each? Why not just create a new object and use it, or, if you needed to be able to handle reuse or do anything else interesting, use a factory for each. The stack traces would kill a tree each time someone needed to print them out. Then again, this was "web services"... I needed a lot of Advil that year.
I've used struts and tiles, and written a wrapper around it that removed most of the pain of creating all those actions and dealing with the struts-config and tiles-config files, ie, a dynamically configurable webapp using a simple key-value storage mechanism for web page design utilizing tile components.
I've also worked with JSF 1.1, 1.2, and a couple of frameworks off of those. They're "interesting" but not really ready for prime time in general, although we did have one project that resulted in an application whose functionality I have yet to see duplicated.
I wouldn't touch EJBs. They are a massive waste of time and a sure way to bloat your project and miss any milestones.
As for persistence, you're generally better off writing your own specific framework abstraction utilizing JDBC directly. I've done this numerous times, and it can vary from anything as small as a hundred lines for simple projects to a couple of thousand lines for a completely dynamically designated DB. Contrast this with the few hundred lines of XML you have to write for the best case of Hibernate or other ORM solutions, or the 45K plus lines of code for the Hibernate and JDO solutions I've personally seen that weren't even all that complicated in DB structure.
And that argument about "gee - if you write it yourself you'll have to recode your persistence layer when you change DBs." How many times have you seen a DB being changed in production? Me? 0. I have supported multiple DBs with a single project, but that's generally targeted to just a few, although one time a project I had supported 8 different DB vendors. That one was... "fun". (and was back in the days before there were any persistence frameworks had we been of a mind to use them)
The real question you should be asking is: does this framework/utility/helper really provide me with any functionality that I wouldn't get from the JDK with a comparative effort? In general for me most things will result in an answer of "no". Take Spring IoC specifically for instance. I already code to interfaces, and writing a factory class takes me a maximum of 3 minutes and gives me compile time type checking. With Spring, it'll take about the same amount of time to write the XML bit provided that it's a simple case and you have to actually run it to see if it passes the runtime type checks. Additionally, if you have anything interesting going on in your factory, like accepting a couple of objects to generate a linked DVO or something similar.... well, Spring's going to take you on a fun ride. And then there's John down the hall who will "tweak" the Spring config for something he needs in a sub object's definition 6 months down the road and holy shit, bugs start cropping up in your code that you spend a few weeks tracking down. (This doesn't happen nearly as easily with coded factories)
So, in general, no, you don't have to code everything from scratch. You have a ton of features built into the JDK to assist you without bringing in any of those 3rd party "helpers" like Apache Commons, for instance. Right now I'm looking into ZK for the front-end framework for my next project to avoid dealing with JSF or struts.
But, if you think about it, you've just outlined some of the processes that drive innovation.
It's okay to work on things that are before their time, or not before their time and simply a dead end road. Otherwise, what have you learned?
Innovation is where there is a problem and you present something to fix said problem. Spring does no such thing. The "innovation" in a Spring infected codebase is to remove Spring.
I'm actually doing that in a Spring/Hibernate codebase right now. It's not a fun process, but once done, it will have fixed an entire slew of performance and security problems and add a properly abstracted multi-component persistence layer working through a proper set of interface APIs so that, say, you can link to an LDAP server transparently and data won't need to be duplicated in 6 different places because the Hibernate/Spring conflagration couldn't handle real RDBMS data structures nor distributed data.
If the only reason you have the IoC code in your code is to facilitate testing, then the IoC code is test code.
MVC (in Spring3)? Really? You mean MVC in Spring 1.x or Spring 2.x sucked? Say it isn't so! So now MVC in Spring 3 is the cat's meow? Excuse me while I take a pass.
Spring's transactions are a massive headache when you need to alter or overload a specific operation. Yeah, it seems "cool" when a simple annotation will give you a "transaction", but later on, when you need to modify one bit of code somewhere in the stream or if you're really daring, have a transaction with rollbacks across multiple operations that weren't envisioned in the original design.... let's just agree to disagree and you can deal with all the crap that Spring heaps on you while you cut and paste code and debug it a week later when individual operations change due to changing requirements and I'll be at the bar sipping something cold and enjoying myself after an hour or two's work.
You didn't even mention Spring Security (ie, Acegi) which was so horribly broken 1.5 years ago that it is completely unusable in anything resembling a commercial application. Why, you ask? (I just know that was on the tip of your tongue) Because Acegi as of the current release at that time uses a token held by a thread, and limited the ability of a token to be held to a single thread. In layman's terms - there's only a single lane on the highway, folks.
I still stand by my statement of years ago: Spring is a solution in search of a problem and is a source of not so subtle bugs which most will only realize once they're in far too deep to easily pull out. It truly deserves a picture next to the kool-aid in the wikipedia story about project killers.
I will agree that JUnit4 is pretty darn decent all by itself. Without Spring.
And just in case you think I haven't worked with it - I've dealt with 4 separate large projects and analyzed the problems in various external codebases in 3 different companies that bought into the Spring kool-aid all the way back to before Spring 1.0. I shamefully admit I was even a proponent in the early days, before I actually used it in a big project. Now Spring has joined Apache Commons in the list of libraries to remove asap.
That'd be the #1 reason on the long list of reasons why Spring sucks. IoC. It's main raison d'être, from the initial release, was to allow the injection of test code, ie, mocks. Why on earth would you ever have "test code" in your production code? Much better to have a test framework instead. Harder to code initially, yes. Less invasively? Immeasurably.
Not only that, it's merely a factory method call that can generally be coded in 4 or 5 lines and be type checked during compilation instead of runtime (a la Spring).
Care to try again and with an actual reason this time?
Slashdot Mirror
Yeah, I vaguely recall Ventura Publisher. That's a trip down memory lane.
I'm probably wrong about "2", not about there being more now though.
Forgot to respond to this part: You're wrong on both counts. Sorry.
Ahh, but Minix is the reason Linux exists. :)
GEM was late 80s and pretty much died by 1991.
There was also Deskview 386, a spiffy little product that allowed multi-tasking DOS environments - up to 4 I think. It's been way too long to be sure.
OS/2 in 1987 was not what most people relate to as OS/2 as it was 16 bit for starters and did not have the WPS. OS/2 2.0, which was barely usable as it had extremely limited driver support so you had to buy specific hardware was released in 1990 IIRC. OS/2.1, the first version that approached real consumer usability was released in late 1990 and actually worked quite well.
And I did use many of those, and others on other hardware platforms. (Acck - admitting somewhat my age... bleah!)
I run my own business now. I get quality work done in short amounts of time, and enjoy life with all my free time. If my business went under, I think I'd have a really hard time going back to an office job. I'm spoiled rotten.
And that's why you do the intense bits of coding - 100+ hours a week for 3-4 months straight. If it's something you believe in, you can pull it off. However, everyone has their limits and they're all different. Some can only handle a few days, others months. Most drop off around 6-9 days of 12+ hours per day.
But - the real measure isn't how many hours you code, but how functional and well designed and maintainable that code is when you're done. Sometimes I wind up with less code after 12 hours than I started with, and it does more. (One of the benefits when you work for yourself is your productivity is not measured by LOCs).
You're not entirely correct:
Microsoft and IBM entered a lopsided contracted partnership (in MS's favor as it turned out) to build OS/2. One of MS's pieces was the filesystem. For every copy IBM sold, it was reported they owed MS $79 for the HPFS filesystem. HPFS386 was even more expensive, by another $100+ IIRC.
MS decided they could make more money faster with their own, and first release windows 95, and then NT when they had decided to break their relationship off with IBM.
First, Gnome reminds me a lot of PM's operation.
Regarding the OSX dock, I never use it. I much much prefer Quicksilver and the quick Cmd-[Shift]-Tab and Cmd-[Shift]-` key sets coupled with spaces.
There were also some interesting pieces in the underlying system, such as HPFS. The fact that it was inherently non-fragmenting was a source of incredible frustration for all the NTFS users. :) Then there was the actual functional TCPIP stack (also taken from BSD IIRC, like MS's, but not nerfed)
Per platform, I would say yes. Especially on the "PC". There was DOS and OS/2.
I could add the following for x86 during the OS/2 era:
So I'd say there were a buttload more OSes available then than now.
Considering I ran it for years with no issues, you were either doing something really really farfetched, or did something else that screwed up something in the OS. Oh, and when I say I ran it for years, it was my main work machine that also ran SMTP, FTP, Telnet, Gateways, and did coding and FEM modeling work, data reduction, etc. And those latter pieces were on files up to several hundred MB, so no, it wasn't idle much nor rebooted very often either - usually on the order of months. (486-66 with about 256MB of RAM and 2GB of disk space.... yes, those were the days of limited hardware resources)
I agree with Improv - OD was an awesome product that delivered on the OO promises made for WPS.
...and just not go back to Linux since there was nothing Linux did that Windows didn't.
You either have a MS world view, a peculiar use case, or just don't know what you're talking about.
Try running LDAP on Windows. Can't do that.
Try running a 0 priv service that utilizes a users credentials and changes a different user's password. Can't do that without some serious gymnastics that involves using a SYSTEM or equivalent process.)
Try executing a script utilizing pipes out of a daemon process (closest thing is a service in windows land) You can't.
That's just the beginning of a long long long list of things windows can't do. The list of things windows can do? It's rather short:
Allow a virus/worm in under a service and wreak total havoc because there is no real concept of a lowest privilege process. Oh, and open windows office documents. Can't forget that important one.
I'll still wait a while. With a good HD the OS doesn't lag too much - my boot times are in the sub 30s range even for XP. (about 25s for POST/CD/DVD check, another 25 for the OS to come up)
If I wanted to speed that up - I'd probably add a RAID 1+0 setup and still come out ahead on pricing. (But boot times would probably be slower, since the load time saved would be spent setting up the RAID configuration.)
Since I boot once a month at most, I'll stick with cheap HDs for my desktops for now.
And what specific parameter in any Linux installation error message is likely to point towards the CPU being defective? Most of them would be generic hardware-has-shit-itself errors (DMA failures, null pointer exceptions, hash failures) that could mean any of the cpu/motherboard/ram/psu/hdd are defective. It's impossible, even in principle, for any installer to be able to pinpoint with specificity what hardware is fucked.
Well, having experienced this particular fun with a recent CentOS distribution attempting to be installed on an AMD 939 X2 CPU, the boot and install went great. Reboot into your newly installed wonderful OS? Seems ok. Login. Success! Run a couple of commands and watch the thing pull a Microsoft by falling over dead with virtually no output except for an esoteric error and memory location which was enough to pinpoint the problem. Seems our CPU release had a small piece of errata in it that prevented a certain 64-bit optimization that the CentOS kernel tried to use. Whoops.
Its really too bad that Apple never lets OS-X run in VM on non apple hardware.. then I would be in heaven!
Well, officially Apple doesn't let OSX run on non apple hardware. In reality start here and have fun.
I'm a bit of the opposite to you - I run OSX as my main OS, and run Server 2008 R2, Win 7, and Win XP in VMs (Parallels 5, VMWare 2.0 was still doing software CPUs - don't know about 3.x) and it was certainly freeing - every time windows craps out - snapshot restore and I'm back up in about 5 minutes. I've also got Linux VMs, but generally don't need to run them for testing as often as the coding I do generally transfers fluidly across and all the items I use on Linux also work on OSX.
If we had a truly free market, where there were many providers, then we'd have the mythical market you mention. In reality our version of capitalism always drives towards a monopoly.
Most of the unemployed and many of the employed "programmers" are bad.
Finding bad programmers is easy, it's finding even the merely competent ones that is hard.
Alfresco as far as I know still uses Acegi for security - just be aware that only one call per authorized user can be handled at a time.
Spring sucks.
Give me one good thing it does that's necessary, done well, and not redundant.
Um, integrate hibernate?
You apparently missed my Hibernate spiel. To sum it up - Hibernate sucks to a similar level as Spring, just in different ways.
Simplify EJBs you say? Only if you want to kill any project you're ever associated with, with or without Spring. (EJBs are one of the true Java horrors to come out of Sun, far too pretty in academic terms to ever be practical)
What I was talking isn't anything like that. It's still a conventional mocking framework in a sense that you have to set up mocks & tests yourself (though it does use some neat C# features such as expression trees to make it a lot easier than it normally is). The trick is that they use backdoors in VM to do things that you can't normally do, such as intercepting calls to constructors, non-virtual, sealed or static methods, etc, and injecting your mocks instead of what would have run. Which completely unties your hands with respect to how you design your classes, so that you can do it in a way that's actually sane in and of itself.
I think I see what you're getting at - you're asking if there's something out there for Java that would allow you to do a call to an external object in your method without actually calling it? I don't know.
I do recall looking at something a long time ago that claimed it would auto-magically walk through all your code paths and would test it externally. I still don't really see one. It would require significantly more code analysis in my opinion than anything I've seen to date.
As far as interfaces and decoupling - that's great - on component boundaries. Internally, only if needed. I've seen a "module" that had 13 layers of springified horribleness to execute a single call. I never did figure out why Spring was used, other than someone passed the kool aid around. After all, in your own component code that's making a single functional operation call, why would you need to inject 13 objects into your functional stream? Especially when there's only 1 possible instance of each? Why not just create a new object and use it, or, if you needed to be able to handle reuse or do anything else interesting, use a factory for each. The stack traces would kill a tree each time someone needed to print them out. Then again, this was "web services"... I needed a lot of Advil that year.
Fair question. I like Log4J and JUnit4. :)
I've used struts and tiles, and written a wrapper around it that removed most of the pain of creating all those actions and dealing with the struts-config and tiles-config files, ie, a dynamically configurable webapp using a simple key-value storage mechanism for web page design utilizing tile components.
I've also worked with JSF 1.1, 1.2, and a couple of frameworks off of those. They're "interesting" but not really ready for prime time in general, although we did have one project that resulted in an application whose functionality I have yet to see duplicated.
I wouldn't touch EJBs. They are a massive waste of time and a sure way to bloat your project and miss any milestones.
As for persistence, you're generally better off writing your own specific framework abstraction utilizing JDBC directly. I've done this numerous times, and it can vary from anything as small as a hundred lines for simple projects to a couple of thousand lines for a completely dynamically designated DB. Contrast this with the few hundred lines of XML you have to write for the best case of Hibernate or other ORM solutions, or the 45K plus lines of code for the Hibernate and JDO solutions I've personally seen that weren't even all that complicated in DB structure.
And that argument about "gee - if you write it yourself you'll have to recode your persistence layer when you change DBs." How many times have you seen a DB being changed in production? Me? 0. I have supported multiple DBs with a single project, but that's generally targeted to just a few, although one time a project I had supported 8 different DB vendors. That one was ... "fun". (and was back in the days before there were any persistence frameworks had we been of a mind to use them)
The real question you should be asking is: does this framework/utility/helper really provide me with any functionality that I wouldn't get from the JDK with a comparative effort? In general for me most things will result in an answer of "no". Take Spring IoC specifically for instance. I already code to interfaces, and writing a factory class takes me a maximum of 3 minutes and gives me compile time type checking. With Spring, it'll take about the same amount of time to write the XML bit provided that it's a simple case and you have to actually run it to see if it passes the runtime type checks. Additionally, if you have anything interesting going on in your factory, like accepting a couple of objects to generate a linked DVO or something similar.... well, Spring's going to take you on a fun ride. And then there's John down the hall who will "tweak" the Spring config for something he needs in a sub object's definition 6 months down the road and holy shit, bugs start cropping up in your code that you spend a few weeks tracking down. (This doesn't happen nearly as easily with coded factories)
So, in general, no, you don't have to code everything from scratch. You have a ton of features built into the JDK to assist you without bringing in any of those 3rd party "helpers" like Apache Commons, for instance. Right now I'm looking into ZK for the front-end framework for my next project to avoid dealing with JSF or struts.
But, if you think about it, you've just outlined some of the processes that drive innovation.
It's okay to work on things that are before their time, or not before their time and simply a dead end road. Otherwise, what have you learned?
Innovation is where there is a problem and you present something to fix said problem. Spring does no such thing. The "innovation" in a Spring infected codebase is to remove Spring.
I'm actually doing that in a Spring/Hibernate codebase right now. It's not a fun process, but once done, it will have fixed an entire slew of performance and security problems and add a properly abstracted multi-component persistence layer working through a proper set of interface APIs so that, say, you can link to an LDAP server transparently and data won't need to be duplicated in 6 different places because the Hibernate/Spring conflagration couldn't handle real RDBMS data structures nor distributed data.
Not really - more like arbitrary changes and deletions of functionality, or random renaming of methods. Pick any or all of the above.
and it sucked as much then as it does today.
Just ask the second lemming if he thought it was a good idea.
If the only reason you have the IoC code in your code is to facilitate testing, then the IoC code is test code.
MVC (in Spring3)? Really? You mean MVC in Spring 1.x or Spring 2.x sucked? Say it isn't so! So now MVC in Spring 3 is the cat's meow? Excuse me while I take a pass.
Spring's transactions are a massive headache when you need to alter or overload a specific operation. Yeah, it seems "cool" when a simple annotation will give you a "transaction", but later on, when you need to modify one bit of code somewhere in the stream or if you're really daring, have a transaction with rollbacks across multiple operations that weren't envisioned in the original design.... let's just agree to disagree and you can deal with all the crap that Spring heaps on you while you cut and paste code and debug it a week later when individual operations change due to changing requirements and I'll be at the bar sipping something cold and enjoying myself after an hour or two's work.
You didn't even mention Spring Security (ie, Acegi) which was so horribly broken 1.5 years ago that it is completely unusable in anything resembling a commercial application. Why, you ask? (I just know that was on the tip of your tongue) Because Acegi as of the current release at that time uses a token held by a thread, and limited the ability of a token to be held to a single thread. In layman's terms - there's only a single lane on the highway, folks.
I still stand by my statement of years ago: Spring is a solution in search of a problem and is a source of not so subtle bugs which most will only realize once they're in far too deep to easily pull out. It truly deserves a picture next to the kool-aid in the wikipedia story about project killers.
I will agree that JUnit4 is pretty darn decent all by itself. Without Spring.
And just in case you think I haven't worked with it - I've dealt with 4 separate large projects and analyzed the problems in various external codebases in 3 different companies that bought into the Spring kool-aid all the way back to before Spring 1.0. I shamefully admit I was even a proponent in the early days, before I actually used it in a big project. Now Spring has joined Apache Commons in the list of libraries to remove asap.
That'd be the #1 reason on the long list of reasons why Spring sucks. IoC. It's main raison d'être, from the initial release, was to allow the injection of test code, ie, mocks. Why on earth would you ever have "test code" in your production code? Much better to have a test framework instead. Harder to code initially, yes. Less invasively? Immeasurably.
Not only that, it's merely a factory method call that can generally be coded in 4 or 5 lines and be type checked during compilation instead of runtime (a la Spring).
Care to try again and with an actual reason this time?