Home

News: Java Succumbing to .NET in my Organization

  1. I work for a federal government contractor outside Washington, DC, and I am part of a small group within my organization that produces small- to mid-scale applications, mostly websites hitting a database, for our clients. The management of my group, who are not technologists, has decided to embrace .NET wherever possible for our applications. They cite that Java applications take longer and run into more significant problems than their .NET counterparts. After talking with some of the developers who are in the trenches, most of them are happy to move to .NET. This even includes some who, like myself, have been certified in and built a career on Java. Apparently, Java is just too hard and too intimidating, especially for beginners. Java and .Net are comparably powerful technologies. As one who has experience with both, I will say that I prefer the Java experience (especially for developing business logic), so I find it discouraging that Java is losing ground in this way in our organization. I have thought about the reasons why and have come up with some reasons (and I acknowledge I am probably not the first to offer these explanations): · Too many frameworks If I want to design a website look-and-feel and page flow in .NET, I use ASP .NET. That’s it. If I do so in Java, I use JSP. Or I use JSP and JSF. Or Facelets and JSF. Or Echo2. Or Tapestry. Or Velocity. The number of choices can be intimidating. And that is just for web design. With persistence frameworks, .NET developers have ADO .NET. Java developers have entity beans and JDO as Sun standards or open-source options like Hibernate, Torque, Spring JDBC, and on and on. Given all the choices for the web design, the middle-tier, and the back end, developers are overwhelmed by the number of permutations of possibilities. I could go JSP/JSF, Spring, and entity beans; or Tapestry, session beans, and Hibernate; or JSP/JSF, session beans, and entity beans; or ... You get the idea. · Too many IDEs... all with weaknesses Closely related to the issue of framework proliferation is the issue of IDE proliferation. Consider IntelliJ IDEA, my favorite IDE. It is an amazing piece of software, but it was really behind the curve on JSP development. And that is a Sun standard! IDEA is also completely unaware of JSF, another Sun standard that has been around quite a while and one whose goal was primarily to facilitate web development in IDEs. If IDEA has this much trouble with Sun standards, imagine how it does with open-source solutions like Spring and Hibernate. Sure there are workarounds and plugins and so forth, but those take time .NET developers don’t need to take. Of course, if, for example, developers want to use JSF, then they can go with NetBeans, which is offered free from Sun. But then they forego the incredible refactoring capabilities and “smart coding” capabilities that make IDEA so great. For Java developers, it becomes a matter of deciding which IDE is the least incomplete for their needs. Developers in .NET have no such decisions to make. · Too many infrastructure component possibilities Developers in .NET have Windows Server and IIS. That’s it. All development organizations have professionals devoted to these technologies. Java developers have Tomcat or Apache, for example, for the web server. If they need to deploy to a full-fledged J2EE server, then there’s WebLogic, OC4J, JBoss, and on and on. Developers need infrastructure staff trained in the organization’s preferred server, and the staff might need to be retrained should this change. In my organization, there is no such staff dedicated to J2EE infrastructure as there is with Microsoft infrastructure. It should be noted that deployment to IIS is a simple matter for developers—as simple as copying the project to the wwwroot folder. Java developers must build WAR files or EAR files in order to deploy across servers. Not terribly difficult thanks to Ant, but still more work than a simple copy. What bothers me the most is that these problems negate two distinct advantages that the Java community has over .NET: · Open-source energy Microsoft has a lot of talented people working to improve .NET, but no single entity is capable of the creativity of many entities. There is also the possibility that Microsoft creativity may be somehow subject to the company’s corporate aims. Both of these factors can potentially limit the ability of developers to deliver the highest quality software in the least amount of time. Because no one quite owns Java, much to the chagrin of Sun, there are a lot of great open-source tools out there like Spring, Hibernate, and Struts that result from the efforts of many brilliant, dedicated individuals. The Java community should be able to benefit from this universal effort, and it should be an advantage over .NET. Yet instead it has become a detriment. · Manifestation of agile methodologies within tools The Java community embraced agile methodologies well before .NET did (if it even has). Tools created to facilitate agile practices like JUnit, Ant, and CruiseControl, all of which are open-source incidentally, were developed in Java for use in Java projects. Moreover, many leading IDEs like IDEA embraced these tools as core components. The result was a generation of IDEs that served as a one-stop shop for coding, configuration management, automated unit testing, and automated builds. The .NET community, on the other hand, lagged behind the Java community in all these areas except for configuration management. And even there, Visual Studio .NET only integrates with Visual SourceSafe, another Microsoft product, rather than the all the other choices like ClearCase, Subversion, etc. In the area of other tools related to agile methodologies, only after some time did the fledgling open-source community on the .NET side create equivalents—NUnit, NAnt, and CruiseControl .NET—to their Java counterparts. Agile methodologies transcend implementation technology, yet Microsoft seems to not be quite on board. Only the most powerful, and most expensive, edition of Visual Studio .NET 2005, has NUnit integrated. No such luck with NAnt. As with open-source energy, the agility advantage has not proved to be a boon for Java. This is because the business community has not grasped the business value of agile techniques—particularly in my organization. Therefore, the advantage Java has in this regard is meaningless. Again, the technologies are comparable, so the issue is development speed and ease. Ultimately, I think it comes down to the IDEs. If Java development tools allow for rapid development and help to ease a lot of the pain associated with configuration and such, then this would narrow if not close the gap with .NET. Visual Studio 2005 has a number of really compelling features that make development fast and easy and far more palatable to my management. It is no small challenge, however, for the Java realm to accomplish such a feat with the myriad of frameworks out there. Perhaps the answer is IDE standardization. JSR-198 is a very weak start but a start nonetheless. All IDEs could be built with some minimum standard functionality—like support for all production standards from Sun like JSF and JDO and standard development functionality like drag-and-drop web design. Another standard capability, as Eclipse has pioneered, would be plugin integration and a standard interface for development with the plugin inside the IDE. It would be the responsibility of open-source framework developers to build their software so that it can be incorporated into the standard IDE according to the rules for plugin integration. In this way, Java developers could leverage the power of the open-source movement and agile methodologies while maintaining the simplicity enjoyed by .NET developers. I would love to hear your thoughts on this topic. How can I convince my management not to abandon Java? Message was edited by: joeo@enigmastation.com

    Threaded Messages (324)

  2. One aspect to consider is that the activity of the Java and .Net communities is a strength and a weakness of both. .Net tends to have a very inactive user community compared to Java because .Net developers are, for all intents and purposes, powerless compared to Microsoft; when MS decides to change how things work, no matter how drastically, .Net developers have little choice but to follow along. Thus, they tend to shut up and follow. On the other hand, Java developers have a huge amount of power. If Sun advocates something that doesn't actually manage their needs, developers stay away... and the JCP views Sun as a participant and not a driver (well, for the most part.) As a result, Java developers are very loud, so to speak, and certainly more powerful than their .Net counterparts. In many ways, what you're pointing out is the strength and viability of the Java community - strength through diversity - against the "strength through monoculture" of the .Net community. It's "safe" to follow MS - everyone else does it, after all, and using Java requires actually participating in the discourse, one way or the other. Your company is choosing the more quiescent path.
  3. In many ways, what you're pointing out is the strength and viability of the Java community - strength through diversity - against the "strength through monoculture" of the .Net community. It's "safe" to follow MS - everyone else does it, after all, and using Java requires actually participating in the discourse, one way or the other. Your company is choosing the more quiescent path.
    Actually, one could make an argument that the Java Community is part of the problem. IT Management, for the most part, doesn't care about "community" and the old adage "noone got fired for choosing Microsoft" is lot more powerful of a factor than "a vibrant community" with open discourse. That doesn't mean that honest discussion can't take place, it's just that, in the Java community lately, it doesn't seem to happen. The bottom line is that a sale must be made. IT technologies survive by money being allocated towards their use. .NET has the least resistance versus a community that uses scatology, ad hominem attacks and backbiting between open source "visionary" framework builders to nullify each other. I'm not sure I'd classify that as diversity and power of choice. The managers I work with could care less about all the egos battling it out in the current arena. They are wary of choosing one technology, irrespective of technical/business value, only to have a blogger with some weight in the community use hyperbole to gut that same framework with no valid counterpoint other than "it sucks and anyone who uses it is an asswipe" and "my framework is better 'cuz I say so" and have a competing manager slap him in the face with it at a Friday meeting in front of the boss. From a technology standpoint, Java is still the way to go for current IT problem domains with the exception of the presentation layer. It's this tangible layer that management sees day in and day out, and where Microsoft has a significant lead for better or worse.
  4. To start with really great post. There are quite a few companies out there dropping J2EE (not especially Java) and truning to .NET. They have been burnt with so called architects who made projects fail when they picked the wrong framework/product for the job. I must admit I can see their point because why would you not turn to a technology where it may not be the greatest but your chances of getting burnt by bad technology choices (because their are very few to make) are small. At the end of the day you need smart and experienced people if you are going to work in a technology like Java where they are lots of choices and pot holes. Sadly those people are thin on the ground and with the market picking up the numbers are getting even thinner.
  5. It’s always the same. Someone rightfully complaining about the proliferation of very similar frameworks and tools and someone answering that we need them. We don’t. It’s as simple as that. Some people claim we can simply evaluate what’s best and use that. We can’t. 1. Whatever the claim the evaluations are a major work to be done. We have better things to do. (And we do many evaluations so we know.) 2. A major issue here is waste of effort in making similar things. We do need 2 or 3 of each for the sake of competition, but not 5 or 10. 3. When there are so many alternatives some of them will be badly designed, but still hailed by many users so it’s hard to find out what to use and what not. 4. In some areas you are wrong though: There are essentially only 2 IDE’s. All non open source IDE’s will disappear due to all the money and effort spent on the open source ones. For DB access there seems to be only Hibernate and iBatis (although non of them seems to be by far as good as they could and should be by now – by far!). May be there aren’t really that many tools for web development either, but that’s where the major problem seems to be right now. Also there don’t seem to be any clear tool and/or framework winners for Swing development. (But things are happening and Swing have clearly – and luckily – won over SWT.) 5. Look at Microsoft and what they do. Visual Basic used to be the best tool around for a lot of GUI development (no competition in sight on MS Windows at it’s height actually). Then they made it object oriented and compatible with .NET in a way that essentially rendered all old code next to useless. To a significant extent they have also done similar things with c/c++ not only during the upgrade to .NET, but also through earlier library changes. Java programmers generally so misunderstand Visual Basic that they aren’t even close to making these Microsoft problems into advantages for Java. This is of course where Java also has some problems without the right framework and to some extent tool choices. The basic solution is for you to make the right choices and tell your organization: Look, Java has the best frameworks, tools, utilities and whatever you need. You also gain the greatest independence from any company or organization that has ever been seen in the development world. It’s likely you can live with these right choices for a very long time and you can expect them to be significantly enhanced year after year in an upward compatible way. Very significant for any sane company. And even if you should be wrong in a choice of some product most of the time it isn’t all that hard to switch – and at least you do have that option.
  6. ... .Net tends to have a very inactive user community compared to Java because .Net developers are, for all intents and purposes, powerless compared to Microsoft... Thus, they tend to shut up and follow.
    I don't have a good explanation why several .NET sites are less active than their Java counterparts, but saying that .NET developers are powerless is wrong: Microsoft is obsessed with feedback, they understand that if developers find too hard or simply don't like the way Visual Studio or .NET Framework do something, they will look for alternatives (Java, Ruby, etc.) Ditto for a browser, database, or operating system. Thus, just out of market laws, Microsoft *desperately* wants happy developers. And, about the "they tend to shut up and follow" law, you should see the Regional Directors discussion list: when they are asked (and even more so when they are *not* asked!) to give their opinion about any new feature, framework or product, the RD's do nothing close to shutup and follow :-)).
  7. ... .Net tends to have a very inactive user community compared to Java because .Net developers are, for all intents and purposes, powerless compared to Microsoft... Thus, they tend to shut up and follow.


    I don't have a good explanation why several .NET sites are less active than their Java counterparts, but saying that .NET developers are powerless is wrong: Microsoft is obsessed with feedback, they understand that if developers find too hard or simply don't like the way Visual Studio or .NET Framework do something, they will look for alternatives (Java, Ruby, etc.) Ditto for a browser, database, or operating system. Thus, just out of market laws, Microsoft *desperately* wants happy developers. And, about the "they tend to shut up and follow" law, you should see the Regional Directors discussion list: when they are asked (and even more so when they are *not* asked!) to give their opinion about any new feature, framework or product, the RD's do nothing close to shutup and follow :-)).
    And then they hand the list to the marketing departement who throw it in the garbage and ask to have software automatically installed with no user interaction.
  8. I do work in Federal,We have some applications in Java and .NET. It's chaos. It's my observation that technology usage is also influenced by. 1:Budget 2:Technolgy Marketing,like Microsoft is very good at. 3:Different pricing for Federal sector 4:Multiple dev teams in Orgs, with different skills set 5:Software company relations with Org upper Management 6:Most importantly;Microsoft is shipping every thing in one BOX (2003) IIS,OS,frameworks , and one IDE 7:Technolgy un-awarness of Org Management 8:Requirements The list can go one.
  9. I see a lot of "too many" in your post: so your organization is not able / worried to make choices? Many alternatives in the Java world means a vibrant community, competion and quality. In the .NET world you have to digest what Microsoft decides is best for you, full stop. That is not too bad if you are just happy with all the tools .NET provides. Of course, if you need to select a tool / library / app server / framework you need to know what it is about. Generally speaking this kind of fear looks to me typical of organizations without a technical decision maker that is capable to give his/her IT a direction. My experience is the opposite, at least in Europe I can see more organizations leaving .NET in favour of Java, especially if we are talking about enterprise-level systems. In Europe is generally easier to find good Java developers: universities teach Java and OO in programming courses, while many (not all, luckily) .NET developers are "recycled" VB hobbyist without OO experiences. At the end, why are you so worried about your management voting for .NET? A good developer can do a lot with .NET, at the end architectures and good designs make a difference, not really supporting technologies. then, it's your management's decision, so you will have someone else to blame. Personally I like Java, however with .NET you can learn someting new and add it to your CV.... My only advice is: be pragmatic and not religious! Regards, Maurizio
  10. O.K. First before people start going off their nut, I want to clearly establish that I am not a Microsoft bigot. Quite the contrary, I have been using Java since JDK 1.0 and with the introduction of J2EE, distributed solutions. Recently, I have starting using Microsoft's version of C# and the .Net framework. In the particular IT space I am it, my customers wanted it, so that was that. As a framework, there is a lot to like about .Net. It seems complete. Simple things like text and date formating are piss easy. Of course the .Net framework has had the benefit of hindsight, whilst the JDK APIs evolved. I want to be clear. I am not talking about C# and how it is a rip-off of Java, yada, yada. I am talking about the .Net framework. Some of the characterisations the writer made are slightly off the mark. There is an SVN plugin called AnhkSVN. It is not feature complete as say Subclipse, but it is there and it does work with lower priced versions of Visual Studio 2005. If a customer has an established infrastructure of Windows clients and servers, and they show a preference for .Net than of course I will work with that. I am not going to go out of my way and be a Wally and try to push a J2EE solution. If a customer has an established Unix or heterogenious server enviornment, then of course I would be recommending J2EE. At the end of the day I am not dogmatic one way or the other. I started out building distributed systems with Forte Software, so I am not wedding to Java/J2EE or .Net. Personally, I would rather build distributed systems with Forte. But alas, Sun sank that ship after acquiring it.
  11. I have managed and delivered both .Net and Java projects. Every project delivery that has a finite effort and scope. If my Project delivery is my "End" then .Net or Java is just a "Means" towards it. From my experience I can say that the "vibrant community" of Java architechts and developers I have worked with have always invariably spent all the "finite" time on the choosing "means" at the cost of the "end". This of course comes due too the choices available in Java. Do I care ? Of course not... From a delivery perspective I would say that it's always easier to manage a .Net project. I guess I can understand why the organisation chose .Net
  12. These arguments all seem to boil down to a simple belief withing your company: Choice Is Bad. Regarding Web Frameworks - you're right there is a bewildering array at the moment, which is a natural result of the open source energy that you mention. However you don't have to evaluate each one as an equal - there is a quite clear set of about three "leading" frameworks. You can devote your energy to evaluating which of those best fits your needs. Having a choice of only one framework (ASP.NET) may seem to be easier, but what if ASP.NET doesn't fit your needs? Regarding IDEs - there are three leading Java IDEs at the moment: IntelliJ, Eclipse and NetBeans. The competition between Eclipse and NetBeans is driving them to ever higher levels of functionality and ease of use. IntelliJ is struggling to keep up, you will find there is good JSP support in both NetBeans and Eclipse. Compare this with .NET where you have only one IDE available, and it can't even do basic stuff like refactoring properly. Since Visual Studio.NET has no competition and is not open source, only Microsoft is driving it to improve - and they have a limited imagination. Regarding ease and speed of development in general, I think that the productivity gains achieved with Microsoft tools and platforms is largely illusory. It is true that Microsoft tries very hard to make certain things easy, and if they anticipate that you would want to do something in a particular way, then they will provide all the wizards and auto-configuration magic to make sure you can achieve it with barely a few mouse clicks. On the other hand, if you want to do something that Microsoft did NOT anticipate you wanting to do, then things suddenly become inordinately hard, or literally impossible. In comparison to this, Java retains a great deal more flexibility so that, when you need to do something genuinely hard or complex or ground-breaking, you can. The price we pay for that flexibility is that the really simple things cannot be achieved with just a few waves of a magic wand, but I believe that's a price worth paying.
  13. Choice is bad for staffing[ Go to top ]

    There's one additional problem to consider: The bigger the choice of frameworks, the lesser the chance that you'll get the one developer that is productive in your specific framework mix. I always see problems in hiring Java developers when it comes to real-life experience with frameworks. Many have tried this and that, read books and whitepapers, but can handle only a handful of frameworks in a mature and professional way that would require deep knowledge about the technology. Framework scatter is choice, but it contains the risk of not reaching your stakeholder's aims. And finally it's them that pay your work. And usually they don't care about the design details.
  14. These arguments all seem to boil down to a simple belief withing your company: Choice Is Bad.
    I don't think that's true. I have worked with both Java and .NET and there is more to the simplicity of .NET than wizards and the lack of choice. The main thing is J2EE's inadequate deployment/redeployment model. It's simply too complex and too slow for development which leads to a situation where each app server vendor and tool maker invents their own workarounds. Just look in the forums of any tool or app server. You'll find a huge number of postings asking why this or that is not loaded or reloaded as expected and what can be done to speed up turnaround for larger applications. People don't find anything in those weird temporary structures created by all the tools and deployment processes. Everything is duplicated three or four times, copied, zipped, exploded, etc. Why are html pages, CSS files, images, JSPs, etc copied to a deployment/staging directory, zipped into a jar, copied to another directory, and then unzipped by the app server in yet another directory? Why is there no standard way, observed by all app servers, to leave all this stuff in place? Why was the J2EE class loader hierarchy not standardised? Why has nobody thought of the whole deployment process in a pragmatic way that doesn't make hordes of J2EE developers wait ages for ant scripts to finish and debug reloading issues? Now, don't tell me that this or that app server deploys this or that jar thingy really really smoothly. I know that, I've been doing this for a long time. But deployment/redeployment has always been complex, slow and error-prone. Some kinds of issues just never seem to go away. Something always goes wrong. The J2EE spec was very "wise" to introduce a separate deployer role. Unfortunately, it's not just a role, it's a job. A job nobody wants to do and only big companies want to pay for because they have deployment complexity anyway. Choice can work very well on top of a sound platform.
  15. Choice is not a bad thing. However, the problem with Java is that quite often all of these choices just don't offer truely powerful solutions (yes, there are exceptions like Hibernate). You just have all these really cool, but not quite 100% fragments. If you want to build a web environment, you can take Struts and it's quite good. You'll probably lose (waste) a lot of time with configuration files etc and trying to get a multilingual validation up and running, but generally: a good framework. Then you get to the UI. So you look and you think: JSP is the standard, I'll take that. Next, you find yourself looking for GUI components here and there and trying to integrate them. Developing in JSP is a nightmare so that's a time killer right there. As far as the GUI goes, we have *finally* seen some good stuff coming out recently, but up till now I just couldn't believe how bad the tooling is in this area. Whenever, SUN comes out with something like JSF or AJAX components, it's just "back to 1995": look we can do a form!!! Creating something that looks slick and cool also means you actually tried to do something with the framework that we all have to do in the real world. Let's get out of this Hello World mentality please! Compare this to the stuff Microsoft comes out with and you'll know what I'm talking about. It's simply: production power. Not all of us have to build enterprise, super scalable stuff. I love Java but I just don't want to spend my time fiddling with thousands of XML configuration files for thousands of half complete open source solutions, wasting time, reading manuals and being frustrated. I want solid development power, out of the box, looking slick and cool and working well. Not too much to ask I would say.... Cheers, Marc
  16. These arguments all seem to boil down to a simple belief withing your company: Choice Is Bad....
    It is bad when you have to make choice for too many things. I'd say it's mostly Sun's failure - they failed to make a dominated modern web framework, an IDE, an ORM, .... they can't even make their j2ee server standing against the others, yet they just don't embrace the other dominated ones either, instead they seem to be trying to split the markets and make themselves look like a desperate 3rd-party tool vendor.
  17. These arguments all seem to boil down to a simple belief withing your company: Choice Is Bad....
    It is bad when you have to make choice for too many things. I'd say it's mostly Sun's failure - they failed to make a dominated modern web framework, an IDE, an ORM, .... they can't even make their j2ee server standing against the others, yet they just don't embrace the other dominated ones either, instead they seem to be trying to split the markets and make themselves look like a desperate 3rd-party tool vendor.
    Since I don't have to use Netscape/SunOne, having more choices isn't bad. It helps to keep the other EJB containers moving. Take the case of microsoft. Since there's only IIS, Microsoft will move at the pace they want. There's no urgent need to improve IIS. If there was a viable alternative to IIS that is API compatable, you'd see IIS improve faster. Even though Mono has XSP, it's not a real contender. peter
  18. These arguments all seem to boil down to a simple belief withing your company: Choice Is Bad....


    It is bad when you have to make choice for too many things.

    I'd say it's mostly Sun's failure - they failed to make a dominated modern web framework, an IDE, an ORM, .... they can't even make their j2ee server standing against the others, yet they just don't embrace the other dominated ones either, instead they seem to be trying to split the markets and make themselves look like a desperate 3rd-party tool vendor.


    Since I don't have to use Netscape/SunOne, having more choices isn't bad. It helps to keep the other EJB containers moving. Take the case of microsoft. Since there's only IIS, Microsoft will move at the pace they want. There's no urgent need to improve IIS. If there was a viable alternative to IIS that is API compatable, you'd see IIS improve faster. Even though Mono has XSP, it's not a real contender.

    peter
    That's true, but it's better if there is one server controlling more than 50% of the market - and is supported and promoted officially. When a beginner comes, you would want to tell him to start with this and that, not to make choices on what he doesn't understand yet.
  19. beginners are suppose to suffer[ Go to top ]

    I may be demented, but I believe beginners should have to struggle. Where's the fun if there's no struggle. Is it more satisfying to click a few wizards and not understand a tool, or is it better to take time to learn how something really works? To use a poor analogy. I worked fulltime in college, and appreciate my education. My friends who never worked in college and had everything paid by their parents think nothing of college. To them it was just drinking beer and parties. peter
  20. I may be demented, but I believe beginners should have to struggle. Where's the fun if there's no struggle. Is it more satisfying to click a few wizards and not understand a tool, or is it better to take time to learn how something really works? To use a poor analogy. I worked fulltime in college, and appreciate my education. My friends who never worked in college and had everything paid by their parents think nothing of college. To them it was just drinking beer and parties.

    peter
    Exactly, they need to struggle, but not to make choices before that ;)
  21. Not the emotional debate again[ Go to top ]

    I was consulting for a large communications company that have both Java and .NET applications and helped them integrate the disparate applications via Messaging and Web services. Whilst I was there the company IT management made a strategic decision to go with .NET/C# as their platform of choice for future enterprise application development. Their reasoning was that at enterprise level Java solutions(the pricy Web logic and Oracle db etc...) were costing them more than the .NET/C# solutions(They had figures to prove it). From a technical standpoint for me it was not Java or .NET, it was the architecture stupid. If the implementation is based on a great architecture, what you implement the architecture with does not matter much. Hold on I do agree in general that many .NET developers have VB(read programmers who struggle with OO concepts and design patterns in general) background. I myself have a VB experience and consider my self a good developer. I see application development tools as commodities so its a matter of get the best value for your buck IMHO. Disclaimer, I happen to like what M$ is doing around the .NET/C# generics etc... Shepard http://shepardtowindo.blogspot.com/
  22. It depends on a lot of things. For example, what kind of products/services the company is providing, what is the mix of developers, the culture amongst the leaderhip (just imagine an ex. VB fanboy). I was able to sell Java with open source. I think there is value in that, and if you are succeeding in your projects, other people see the value as well. Choice is not a bad thing when you need to be "agile". I have also been very diligent in building a solid reusable foundation libraries, something that the .NET developers have failed to do in the company I work for. I just use that as a trademark of a Java developer to create some prestige around the whole thing. So, if you can, tie in your success with Java. One thing that seems to help is the willingnes to be open and integrate with .NET software when appropriate. There are a lot of .NET guys who do not understand Java and are not willing to look over the fence; so demonstrate that there is no language jealosy and that software can work together just fine. The other point of this is that you can now diversify your developer base - developing software is still about the people and their skill, so if you can find Java talent, you can use that in your company.
  23. Getting a clue...[ Go to top ]

    This post inspired a blog entry. First off, I can't understand why having choices for IDE's and frameworks os a bad thing. However, the main point of my blog entry is that I believe that the vast majority of developers just don't get OO. They prefer the "fill in the code behind the form" model of development... thanks very much Alan Cooper. If more people did get OO, this post likely wouldn't exist. Of course, if that were indeed the case, Java probably wouldn't exist either and we'd all be programming in Smalltalk. The bottom line is that until developers get a clue about OO, tools such as Visual Studio that promote brain-dead practices will thrive. FWIW, I'd love to be proven wrong. Dave Rooney Mayford Technologies
  24. Re: Getting a clue...[ Go to top ]

    I fail to see what this has to do with the .NET vs. Java choice. Unless you believe that people using .NET are fundamentally different from those using .NET (and reading your post are a lower life form). I can not see what is wrong with people using some wizards to write a simple program. Of course, if your program gets bigger, an OO approach will certainly benefit you, but as the program grows, one I can refactor it (You should know, considering the company link in your post). I do agree that many programmers know how to use OO libraries, but only few know how to write them. But that is a mentality problem. At my job there was someone using C/C++ and managed to write 6 methods in one file, that file being 12000 (yes twelve-thousand) lines long, which makes an average of 2000 lines of code per method. He refused to use classes because they would slow down his code and the code for copying a structure was written down every time he needed it because "using a function" would slow down the code. This was done without any testing of speed, but just him not trusting C++. I hope you do not consider Bjarne Stroustrup being responsible for this. I do agree with most of the content of your post, but do not agree that it is a .NET vs. Java problem. It is a problem of genuine interest in your job, or coding because during the internet bubble the industry was desperate for programmers and you jumped the wagon. And still, if you can satisfy your customers wishes with clicking some wizards, what is wrong with that? In the end, it's cusomer satisfaction that is important, no? Serge Desmedt
  25. Re: Getting a clue...[ Go to top ]

    I fail to see what this has to do with the .NET vs. Java choice.
    From the original post:
    After talking with some of the developers who are in the trenches, most of them are happy to move to .NET. This even includes some who, like myself, have been certified in and built a career on Java. Apparently, Java is just too hard and too intimidating, especially for beginners.
    Why is Java too hard and too intimidating? Because a very large number of developers don't have good (if any from code that I've seen) OO skills. When you create a new application or project in VS 2003, what does it do? It pops up a nice blank Windows Form for you. You then just fill in the blanks, embedding business and possibly data access logic in the presentation code, unless you have a clue about separation of concerns. I do not believe that .NET developers are a lower form of life. What I do believe is that many of them either moved to .NET from VB, or gravitated to the easy to use GUI tools. What that leads to is applications that may work fine initially, but are difficult if not impossible to extend as warranted by business needs.
    And still, if you can satisfy your customers wishes with clicking some wizards, what is wrong with that? In the end, it's cusomer satisfaction that is important, no?
    What's the statistic for the percentage of a system's lifetime spent in maintenance? Was it 80%? Well, if a system is built upon a good OO foundation, much more of that 80% will be spent in creating value for the system's Customer rather than just trying to keep the bloody thing afloat due to incomprehensible, brittle, highly-coupled code. On top of that, you can deliver business value early and often using agile methods, so that the Customer's insatiable need for "something... anything... NOW!" is still met. Dave Rooney Mayford Technologies
  26. Re: Getting a clue...[ Go to top ]

    I do not believe that .NET developers are a lower form of life.
    Haha, then why is Java the dumbed-down language? Why do Java developers get scared about operator overloading and always praise Java for it's "simplicity". Oh yeah, it's always "the other" java developer that is going to do something stupid with operator overloading. It seems that Java developers think that their fellow Java developers are lower life forms.
  27. Re: Getting a clue...[ Go to top ]

    I do not believe that .NET developers are a lower form of life.


    Haha, then why is Java the dumbed-down language? Why do Java developers get scared about operator overloading and always praise Java for it's "simplicity". Oh yeah, it's always "the other" java developer that is going to do something stupid with operator overloading.

    It seems that Java developers think that their fellow Java developers are lower life forms.
    My beef isn't with .NET or Java per se, but with people who think they know how to develop OO systems because they read a book or took a course. It takes years for people to truly graps the concepts and to build systems using proper OO principles. There are very few people who "just get OO" from the start, and I don't consider myself among that group. What I want to see is more people recognizing that they don't understand OOD and then actually set about learning it. After all, if you don't admit there's something wrong, you can't fix it. Then, and only then, can we have a really meaningful discussion about what languages and platforms are better. What I do see with Visual Studio (and not necessarily .NET) is that, like VB, it coddles the programmer into building a GUI and sticking code into it. Dave Rooney Mayford Technologies
  28. Re: Getting a clue...[ Go to top ]

    My beef isn't with .NET or Java per se, but with people who think they know how to develop OO systems because they read a book or took a course. It takes years for people to truly graps the concepts and to build systems using proper OO principles. There are very few people who "just get OO" from the start, and I don't consider myself among that group. What I want to see is more people recognizing that they don't understand OOD and then actually set about learning it. After all, if you don't admit there's something wrong, you can't fix it. Then, and only then, can we have a really meaningful discussion about what languages and platforms are better.
    First off, I misread your original post, so I apologize for misinterpreting what you wrote. But regarding OO, I think we're also getting to the point that OO is not the panacea that many thought it was in the early, late 90s. Functional programming languages see it as an adjunct and not something that needs to be centrally focused on, depending on the task. But to generalize your statement about reading books and taking courses, I can only agree, and there still seems to be a magic bullet mentality out there. Of course, best practices do need to be documented and I think there does seem to be a shortage of documentation in the style of the Code Complete books, where it's more in the trenches and less theoretical UML gobbly-gook.
    What I do see with Visual Studio (and not necessarily .NET) is that, like VB, it coddles the programmer into building a GUI and sticking code into it.
    .NET is a different animal as you probably already know. It's a much more comprehensive stack for doing things beyond the typical VB app. But the whole point of VB was to "coddle the programmer into building a GUI and sticking code into it". Slap together a form to connect to a database. It was RAD to the extent that Java never achieved. That why it was (as some have suggested) the popular programming language of all time. I've never written a line of VB in my life, but a very bright hardware/software engineer that I used to work with swears by it, because it's just so easy to put together things, rip them apart, change it around, and it just works. Obviously, you're not going to write some big financial transaction system in it, but that was never what it was designed for.
  29. Re: Getting a clue...[ Go to top ]

    Why is Java too hard and too intimidating? Because a very large number of developers don't have good (if any from code that I've seen) OO skills.
    The original post stated 3 main reasons for choosing .NET instead of Java:
    I have thought about the reasons why and have come up with some reasons (and I acknowledge I am probably not the first to offer these explanations):

    · Too many frameworks.

    · Too many IDEs... all with weaknesses

    · Too many infrastructure component possibilities

    Again, I fail to see what this has to do with (most) .NET developers presumably being less talented object oriented developers. The original post mentioned too many choices (frameworks, IDE, infrastructure), but i didn't read any critics on the programming model used. Your statement about .NET developers being ancient VB developers, I will neither confirm, nor dismiss. I do remember however that when .NET entered the programming arena several VB developers where complaining about the changed development model. So I suppose those people had to learn OO techniques. And Java itself hasn't been around for ages neither, what where they using before? (I suppose it would make an interesting subject for a poll: "Through which programming languages did you evolve during your career?") Btw, Object Oriented isn't a silver bullet neither. Now they invented Aspect Oriented to solve some problems with Object Oriented. I think you should always keep an open mind and use the paradigm that most serves your needs, be that functional, object oriented or whatever other. Same goes with tools: if you have a simple application displaying some data from a database, why not use simple drag and drop functionality. If it gets more complex, look further and refactor your application. I thought "Agile" was about that: do the simplest thing possible and refactor when needed. I firmly do believe it is a mentality problem and not a platform/tooling problem. And the original post was about a platform/tooling problem, their being too many of them in Java. Serge Desmedt
  30. Re: Getting a clue...[ Go to top ]

    Same goes with tools: if you have a simple application displaying some data from a database, why not use simple drag and drop functionality. If it gets more complex, look further and refactor your application. I thought "Agile" was about that: do the simplest thing possible and refactor when needed
    I think you touched the root of the problem: it is easier to use drag-and-drop functionality in .Net, but it is harder to refactor. In Java it is the opposite: it may be harder to use drag-and-drop functionality, but it is easier to refactor, given the platform's greater flexibility. So the choice of either platforms must take this into account. Given that most complex project costs lie after development, during a project maintenance phase, IMO java has an advantage in long-lived projects. But if your project is a one-off fire-and-forget solution, .Net may be better fitted.
  31. Re: Getting a clue...[ Go to top ]

    So the choice of either platforms must take this into account. Given that most complex project costs lie after development, during a project maintenance phase, IMO java has an advantage in long-lived projects. But if your project is a one-off fire-and-forget solution, .Net may be better fitted.
    I've written too many "one-off fire-and-forget" solutions that are still around 10 years later. I don't really believe in such things any more.
  32. Re: Getting a clue...[ Go to top ]

    So the choice of either platforms must take this into account. Given that most complex project costs lie after development, during a project maintenance phase, IMO java has an advantage in long-lived projects. But if your project is a one-off fire-and-forget solution, .Net may be better fitted.


    I've written too many "one-off fire-and-forget" solutions that are still around 10 years later. I don't really believe in such things any more.
    Neither do I. And if everyone had learned that by now, there'd be no millionaire power-user consultants left in the world. :)
  33. Re: Getting a clue...[ Go to top ]

    I think you touched the root of the problem: it is easier to use drag-and-drop functionality in .Net, but it is harder to refactor. In Java it is the opposite: it may be harder to use drag-and-drop functionality, but it is easier to refactor, given the platform's greater flexibility.
    But isn't this "just" a tooling problem? A big one I agree, but nevertheless a tooling problem. I didn't like the original answer suggesting that .Net developers are presumably less talented Object Oriented developers (read his blog post). As I mention in my first answer, I know of a C++ developer writing methods of two-thousand lines of code (average, some where even bigger) without having used any wizards, or having a VB background. Does this mean C++ makes less talented OO developers? No, it just means that guy was closing his mind instead of opening it for new things. He had the wrong mentality.
  34. I've worked for a company who made the same choice than yours: leaving java for .NET. It seems that too many choices (even from the same editor JDO/JPA) kill the choice... The worst is in the web framework area where there is not a day without a new annoncement. This is also the same reason why IBM, with it's websphere line, is so popular in the management: one app server, on ide, middlewares (websphere MQ) and everything integrated (on the paper board). I love to have the choice (and not a fan of IBM products) but it's conforting. Only one interlocutor, one support contract. I tried to mix different products to make two phases commit (Webshere MQ, Oracle, JOTM, Enhydra pool connection, Spring) without success. No integration between theses products, almost no documentation for this kind of problem and no support from web forums (I suppose we are not a lot to try to do that). Maybe it would have been more simple if all the products came from the same editor. So, freedom of choice is really important but also very expensive (in time to study the differents choices). I hope that in a near future there will be a concentration from differents open-source projects to let only 2 or 3 leaders (+ commercial products).
  35. It sounds like what makes .Net great is that it takes away the burden of making decisions. That might be ok for less experienced developers. I have been programming long enough to know that I want some say over my development environment, testing tools, frameworks etc... Furthermore, I have been on projects where the tools didn't work quite the way I needed them to or came across a bug. Because I was using open source frameworks and tools, I didn't have to make excuses to management on behalf the vendor supplying the tools and explain how our project would have to wait for someone else to (maybe, when they get around to it) fix it. I just dug into the source and fixed it. For less experienced developers, I could see where this might be too intimidating. I have been on projects where I was locked into a closed source product that doesn't do everything advertised and then you're just stuck. I also developed with Microsoft tools in the early to mid 90's. I will never go back to that again. Personally, I think it's crazy to tie your career to one vendor's suite of products.
  36. I think it's crazy to tie your career to one vendor's suite of products.
    i second that. i dont know what it is but this post seems "suspect" "Way back in the day"(late 90s),all i did was C++,MFC,COM/DCOM... i remeber when .NET came out and MS said we COM/DCOM/MFC is old news..then i had a wake up call i am a MS lapdog developer.. so i found java/J2EE(EJB with all its problems) and worked with that for a few years..now last 3 years lightweight frameworks allows me to developer software quicker(Java,Hibernate/Spring) and XP/TDD ... the post said "too many " phrase just to much.. i work in DC also but don't think the free world is all bowing to .NET, it just seems someone made a "business deal" behind the scene and went with .NET...
  37. You are NOT in a bad spot[ Go to top ]

    .NET is a different world but I think that your company and well as yourself will be OK. I am yet to see a place that suffered horribly by going .NET instead of Java. I actually think that what are you seeing is a developing trend. I see as well increased resistance towards going Java EE for the same reasons as you mentioned. I think that our (Java EE community) desire to have so much choice in Java EE, for everyone to come up with a new "elegant" framework, to show how smarter he or she is than the previous guy is coming after us to bite us. Diversity is a good thing, but when diversity turns into a proliferation people start getting uncomfortable. And I see that discomfort among lots of (very smart and IT savvy) people almost every day. Edmon Begoli http://blogs.ittoolboc.com/eai/software
  38. Your best choice, get a new job[ Go to top ]

    Which platform one uses is really an executive decision. Once it's been made, there's very little a programmer can do. My bias 2 cents. C# is a solid language. .NET framework is great if you do exactly how MS does it. If not, it becomes a royal pain. I wouldn't bother trying to convince the management. the only thing it will get you is grief, which may be goor or bad. Many managers I've worked for don't like choice, because in their eyes it is a risk. A good managers knows better and allows the developers enough room to make decisions. give .NET a try and see if it meets the needs of the project. if it does, then use it. If not, find another job before the project crashes and you get "let go". peter
  39. I second Peter Lin's comments: "C# is a solid language. .NET framework is great if you do exactly how MS does it. If not, it becomes a royal pain." I used to do a lot of Win16/32 programming (some COM) many years ago. I have been almost exclusively in the Java/J2EE space for a long time now, after getting fed up with MS's "functions as implemented" attitude and their general lack of specifications. Recently I have dipped my toe back into C# programming and it has been interesting to see the changes... and the lack of changes. I will try to illustrate with a concrete example. I have been building an Outlook add-in using C# and it has been quite a revelation. The wizard built into VS generates the add-in (as well as the installer) and you can run a "Hello World" example in under 15 minutes. The programming model (APIs) for Office in C# are pretty straight forward. After tinkering around for a while I started to add features and was quickly pleased with the results. First, you start to see non-deterministic behavior of the menus and event handlers... Why? Because the Runtime Callable Wrapper (RCW, the .NET proxy for the COM objects) can be garbage collected, and when GC kicks in your event handlers are toasted. You need to make sure you maintain static references to any .NET proxies you manipulate. Second, sometimes Outlook fails to shutdown. Again this is a .NET CLR / COM problem. The RCW maintains a COM reference count (remember those things?) each time you cross the managed/unmanaged code boundary and if this reference count gets out of whack the calling process does not exit cleanly. Third, version management issues. Specifically Office applications cannot run add-ins compiled against the .NET 1.1 and .NET 2.0 frameworks at the same time (a process is limited to one version of the .NET runtime). MS's newest add-in technology VSTO requires .NET 2.0 while many existing add-ins are based on 1.1. Forth, library management issues. The Primary Interop Assemblies (PIA... good acronym!) can either be loaded from the application or from the GAC. In the case of Office different PIAs are available for different versions of Office, making targeting multiple versions very difficult. Fifth, security. The Outlook security model is very complex (arbitrary/obtuse?). The MS recommended model for secure Outlook access is to call your (signed) managed CLR code from an unmanaged DLL (shim)! Setting that up is definitely not something you'd undertake lightly. Most (all?) of these issues are covered by Microsoft MSDN articles and Knowledge-base entries. I have a profound sense of deja-vu in all this… Doing the trivial things is simple, but doing "real" things turns out to be really hard, and the number of developers that can help you seems to be much smaller than in the Java world. It reminds me of building MFC applications all those years ago, using "Spy" to analyze the (undocumented) windows events, and then hacking in WndProc hooks to implement workaround for bugs. Of course perhaps my experience has been tainted, because I am relatively new to the .NET toolset and I am using COM Interop. It certainly doesn’t feel like the world has changed that much over on the other side of the fence!
  40. Sorry, but if your management is heading down the all-Microsoft way, then there is no point in arguing. Go with them, or leave the company. And if your development leads are "intimidated" by "too many frameworks" or "infrastructure possibilities", then your team is inevitably doomed anyway, and you should resign quickly.
  41. And if your development leads are "intimidated" by "too many frameworks" or "infrastructure possibilities", then your team is inevitably doomed anyway
    I think that is way too hard. Even though my experience with .NET is very limited, I can imagine a group of not-so-ambitious programmers (you know, those with a private life ;)) that are productive with it and fulfill the requirements of their management, in their given environment. If that is so, why shouldn't they stay where they are? I have better things to do (with Java) than argue on such a basis.
  42. And if your development leads are "intimidated" by "too many frameworks" or "infrastructure possibilities", then your team is inevitably doomed anyway

    I think that is way too hard. Even though my experience with .NET is very limited, I can imagine a group of not-so-ambitious programmers (you know, those with a private life ;)) that are productive with it and fulfill the requirements of their management, in their given environment.
    If that is so, why shouldn't they stay where they are? I have better things to do (with Java) than argue on such a basis.
    Don't get me wrong here. I'm not talking about beginners or not-so-ambitious developers, I'm talking about lead developers. Even a small group should have at least one who is willing to stay in touch with new technologies without being scared.
  43. Sorry, but if your management is heading down the all-Microsoft way, then there is no point in arguing. Go with them, or leave the company. And if your development leads are "intimidated" by "too many frameworks" or "infrastructure possibilities", then your team is inevitably doomed anyway, and you should resign quickly.
    +1
  44. It sounds to me like your manager is making the right choice. When you have a group with a lot of "beginner" programmers, and you are producing smaller applications, and you are in a Windows-only environment, it is hard to go wrong with .NET. The fact that most of your colleagues feel comfortable with the switch helps to confirm that this was a smart move.
  45. I am personally cautious about relying on even apparently key development technologies, like .NET, that come from Microsoft. The reason is that Microsoft has a history of changing direction in terms of development languages and tools and leaving many developers behind. Some examples: Object Pascal (their attempt to compete with Turbo Pascal). Microsoft Fortran. PenWindows. Visual Basic 6 (a migration to VB.NET is not trivial). Java may well be primarily under Sun's control, but it is not a single-source product from a source that has a known reputation for dropping even successful products. (Mono, often mentioned in such discussions, is not yet a satisfactory substitute for enterprise-level .NET).
  46. .NET makes a lot of sense[ Go to top ]

    Our products run on both Java and .NET so we are constantly in both. And I have to say, if you are in a 100% Windows environment, I think .NET is superior (personal opinion!). There is a lot of benefit where the entire software stack comes from a single company. They designed it after Java and learned a lot from Java. And with .NET 2.0 it is as solid and full-featured as Java. In terms of development, it's a dream. You can create a web service in a minute or two. Security is integrated into the system throughout - you can access Sql Server on the server using the credentials of the client user (from the browser) without ever seeing the user's password. The list of items like this goes on and on. And VisualStudio supports every part of the entire API. So, take this as an opportunity to learn C#. You will probably find in 3 - 6 months that you agree with the switch to .NET.
  47. Our products run on both Java and .NET so we are constantly in both. And I have to say, if you are in a 100% Windows environment, I think .NET is superior (personal opinion!).
    .NET is "by the Windows, of the Windows and for the Windows." If I were only developing for Windows, and particularly if tight integration with Microsoft products were important, then I'd most probably use .NET. The real idiotic decision by Microsoft was to make it incompatible with Java, which means that developers are typically left with "either / or" choices. In the end, it will be the failure of .NET, because it's an all-or-nothing gambit (and I believe it provable that Microsoft cannot win "all"). Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  48. The real idiotic decision by Microsoft was to make it incompatible with Java, which means that developers are typically left with "either / or" choices. In the end, it will be the failure of .NET, because it's an all-or-nothing gambit (and I believe it provable that Microsoft cannot win "all
    Our code runs on both - and it's not a trivial program. The trick is we have common source, not a common binary. We then compile for each (using J# for .NET). It all works remarkably well. - dave
  49. that produces small- to mid-scale applications, mostly websites hitting a database
    Your description of what your organization does is the best explanation of why .NET is not a bad choice in this case. It is the space where .NET excels. I've worked in a few mixed environments where we did J2EE and .NET (and legacy). J2EE was used for enterprise services and legacy integration and .NET was used for the presentation layer, web publishing and departmental applications. The perception (amongst IT staff) was that .NET was easier to use and very capable in the small to mid space and where the requirements were not too demanding. In this space J2EE was overkill. On the other hand, .NET did not integrate as well and was not powerful enough for our enterprise applications. .NET also fit better the skill and experience levels of the developers we typically assigned to these less demanding applications. Our best and most experienced developers worked on J2EE where they not only needed their skills but had the opportunity to fully leverage them. Even though I'm a Java and J2EE SOA guy, I'd be hard pressed to come up with a technical argument against using .NET for these things.
  50. First I would like to agree with many other posters in that there is nothing wrong with move to .Net. As you mentioned it does have some very real advantages. Here is a list of shortcomings that I've run into: 1. Source code for .net is unavailable. Often you have to wonder through undocumented classes and try to reconstruct logic by looking at the call-stack. As an example, .Net 1.1 web's upload capability is unsuitable for large files. It tries to cache the whole file in RAM. Once I decided to write my own upload functionality in .Net and it was a major pain: no documentation for underlying/infrastructure classes. 2. It's hard to do anything that just a tad off mainstream, but mainstream itself is very easy. Again my example is developing a web app with frameset based design, where frameset definition was generated in the code (it was a dynamic frameset definition). It was rather hard to make to make .Net page-controller to behave properly. 3. Clustering and failover infrastructure is much stronger for Java. You do need to get right app server for that, but with .Net you have very limited options in this area. Now on the positive side .Net has a power of MS behind it. MS usually creates closed but polished software. Take a look at generics. They are much better implemented in .Net, then in Java. String substitution is much better done in .Net (which is important if you want to support other languages). Starting from scratch I would always opt for .Net over Java, unless I really need something that .Net missing. Yet often I end up using Java, because many projects that I work on, require solid clustering and failover.
  51. It's the reponsibility of management and the developer to make sure that they select the right tool for the right project to provide an acceptable solution to the problem. As developers we always praise the merrit of loose coupling. The solution should not be strongly tied to a tool or framework/language/process (.net, java, ruby, php, or python). But rather, the solution should be decoupled so that management can select the appropriate tool, framework, and process to apply to arrive at the solution. So, if your shop is adopting .Net, it's probably the most appropriate tool for this project or group of people (I am sure there are some political factors involved). However, if .Net makes sense, why not use it? If it provides the solution why fight it? *** Some Corrections *** No IDE/Framwork can make you a better developer. Any tool and technology can be misused. Comparing Visual Studio to Eclipse and NetBean is improper since Visual Studio (standard+) is not a free tool, but Eclipse and NetBeans are. Of course you will get more from the commercial tool. Your writeup assumes having too many choices may be a weekness of Java. However, .Net is just one of many choices that a developer has including PHP, Python, and now Ruby (assuming web development). - organic logic -
  52. To me it looks a typical case of "why more is less". When the number of choices available are too many, it is not worth the effort to pick up the best. Management does not find it worth to invest time/resources to pick up the best products/tools available in java domain, so it makes a rule of thumb and goes for all .net technologies. May be, they will end up not having the greatest or best but if it can solve the problem resonably well, it is good enough.
  53. I am using Java in day jobs. But I am starting to open my eyes on other alternatives when deciding what should be the next technology for my own projects. .Net may not be bad for big sites. Since it's just ONE framework, everybody can pick it up and start to talk in the same language. There are some big sites running .NET. .Net seems pretty good in terms of ROI. It's fast to develop. And don't look down upon "recycled" VB programmer. They got the job done, faster than java developers! It's a good management choice if you can find VB programmers. In terms of alternatives, Java is not necessarily the best. I starts to like Ruby on Rails, Nitro, which really get the job done and still non-Microsoft. Python also have django. Lisp can be better if you know the name "Paul Graham" and you can find one or two Lisp masters. It's not you have to use Java because it's marketed as "secure"/"reliable"/etc. It really depends on your requirements. For things in your organization, you may not need to do any un-common things and most of them are covered by .Net, why not choose .Net when it can save money and get things done quicker? Management may not understand technology, but they are not stupid on money. Chris Lu -------------------------- Instant Full-Text Search on Any Databases/Applications http://www.dbsight.net
  54. I would like to say technologies are driven by “Requirements”. There might be a reason that’s why management comes up with .NET. Also, it’s very good for you to learn .NET There is nothing wrong with .NET and JAVA. People are making “hell” lots of money using these technologies. So, learn how to make money instead of wasting your valuable time like this.
  55. Quick...[ Go to top ]

    ...Introduce them to Rails!
  56. MDA and software factories[ Go to top ]

    I studied difference between .NET a Java while writing my thesis about MDA. Microsoft has very interesting MDA like concept - see http://www.dnjonline.com/login.aspx?ReturnUrl=/article.aspx?ID=mar05_stevecook Very interesting. I have found the same analogy to Java web app. frameworks: The majority of MDA tools is Java oriented. That you can generate Java code using at least 20 different tools....
  57. MDA and software factories[ Go to top ]

    I studied difference between .NET a Java while writing my thesis about MDA. Microsoft has very interesting MDA like concept - see http://www.dnjonline.com/login.aspx?ReturnUrl=/article.aspx?ID=mar05_stevecook Very interesting. I have found the same analogy to Java web app. frameworks: The majority of MDA tools is Java oriented. That you can generate Java code using at least 20 different tools....
  58. Management Speaks[ Go to top ]

    I'm a director of IT in my company. One of the key success factors in my organization is a zen-like focus on simplicity. I love the choice of all the Java frameworks, but its really hard to go wrong with "old school" JSP/Hibernate/servlets. No heavy frameworks, complexity, etc. The stuff we build will scale to high heaven cheaply and easily with very little administration. I'm looking to take simplicity to new heights going forward and see if REST architecture can simplify my traditional SOAP XML web services. Perhaps even swap out the very verbose XML for JSON, which is much lighter. I digress. Your management feels they're making a good business/technical choice. You can either get on board, get a new job, or show them that just because there's a dizzying amount of choice in Java that doesn't mean life needs to be complex.
  59. Sounds like your problem is more with the "best practices" in the Java world as opposed to the "best practices" in the .NET world. With respect to only web-apps in the Java world, a best practice is to use Model 2 MVC development (Struts/JSF), use Hibernate, probably Spring. In the .NET world the best pratice is to use Model 1 straight up ASP and ADO.NET without any middle frameworks. You just need to *NOT* follow the "best practice" java development and you will be mimicking .NET development. For example: Too many frameworks: -------------------- If you are going to use ADO.NET and asp why not substitute that with straight JDBC and JSP. Why even bother with JSF/Struts/Tapestry?. It is not apples to apples when you bring in the frameworks. Yes they do exist but you don't *HAVE* to use them. How are the folks in the .NET world getting around without having a JSF/Struts equivalent? Use Model 1 JSP if you just want eye for an eye comparison with .NET. Too many IDEs... all with weaknesses ------------------------------------ Once again if you tie your framework (JSF/Struts)to your IDE you are going to be disappointed. Why not just stick with the one which has a reasonable HTML/JSP editor. As long as you stick to Model 1 you will find MyEclipse/NetBeans suitable. Too many infrastructure component possibilities ----------------------------------------------- Once again its easy to setup a Apache/Resin combo that just does simple webapps. You don't have to deploy a WAR. You can copy over your JSPs and servlets in a directory. Open source energy ----------------- Most of the energy is spent in making better frameworks which you obviously don't want to use so yes, they won't be of advantage to those who stick to .NET best practices. Agile techniques ---------------- I bet Ant is a lot faster than zipping your ASP pages manually and then exploding the zip in your ASP root dir. Once again agile techniques help only if you are following best practices in the first place. If you are manually copying directories to production.. agile techniques are not for you.
  60. another thing to consider, is licensing costs of using .NET platform. we are a small group like yours, but use open source whereever possible, and to minimize licensing costs. in our case using java and scripting languages where practical we will use them. like another person said in this thread, be practical and pragmattic. and in our context, using java and other non-.net technologies make the most sense.
  61. Begin by telling your management that the web page they asked you to build isn't as simple as they think. It needs to be SCALABLE. It needs to QUEUE all requests using message driven beans. (When you talk to them, speak in acronyms, so be sure you say "MDBs"). Then explain to them that it needs to use entity modeling to access the 2 tables of the database, so you will need to use STATLESS SESSION BEANS as a facade to ENTITY BEANS. Also explain that you will shortly replace all the old-school EJB's with the new school EJB's, you know, the POJO ones. Anyway, try not to get frustrated, they are going to have a hard time understanding the ENTERPRISE, and how everything has to SCALE, and how COMPLEX it really is. You have to be really smart to get it anyway.
  62. If what you want do is create a front end to a database or integrate with a Office applications then use .NET. It is quicker than using Java. However if you want to create a highly scalable, highly available application that needs to update numerous databases and legacy systems in the same transaction then use J2EE.
  63. good god!!!![ Go to top ]

    If what you want do is create a front end to a database or integrate with a Office applications then use .NET. It is quicker than using Java. However if you want to create a highly scalable, highly available application that needs to update numerous databases and legacy systems in the same transaction then use J2EE.
    I want to scream! Why do we insist on lapping up the J2EE marketing BS? You have just described 1 tenth of 1 percent of the application space, and that's what we should use Java for? Why on earth isn't Java a good choice for simple applications? It's sad, because there are some fantastic Java frameworks out there, like Wicket that are incredibly easy to use. We just have to take off these "enterprise" blinders and accept that the J2EE marketing has pumped out a tremendous load of bunk over the years.
  64. Re: good god!!!![ Go to top ]

    If what you want do is create a front end to a database or integrate with a Office applications then use .NET. It is quicker than using Java. However if you want to create a highly scalable, highly available application that needs to update numerous databases and legacy systems in the same transaction then use J2EE.


    I want to scream! Why do we insist on lapping up the J2EE marketing BS? You have just described 1 tenth of 1 percent of the application space, and that's what we should use Java for? Why on earth isn't Java a good choice for simple applications? It's sad, because there are some fantastic Java frameworks out there, like Wicket that are incredibly easy to use. We just have to take off these "enterprise" blinders and accept that the J2EE marketing has pumped out a tremendous load of bunk over the years.
    Sorry but this isn't marketing BS when the application has to live for more than 10 years (typical in bank, government, insurances, ...), even when it is only made of simple web pages hitting a DB. Of course, consultants don't care about such things and this is why they always try to promote *simple* solutions. They never had to deal with crazy law reforms. One thing is for sure, Java is the new Cobol. It allows you to be sure that whatever craziness the director comes with (and they call it business *logic*...), you will be able to scale and adapt the application. As agility methods people has stated many times, software development has to embrace change from the beginning, so I don't buy the argument, if your application is simple you should use something else (*cough* Ruby on Rails *cough*). An application always starts simple than the mess happens so I am more comfortable to deal with a little bit more of complexity at first (and seriously the gap is shrinking more and more in the last years) to know I'll be able to handles everything thrown at me. By the way, now it is quite simple to make basic web applications using frameworks like JSF or Tapestry coupled with something like Spring and Hibernate or iBatis. Than you add Maven 2, and you got all this scaffold generation stuff the Ruby of Rail crowd is so proud of.
  65. Re: good god!!!![ Go to top ]

    Of course, consultants don't care about such things and this is why they always try to promote *simple* solutions.
    Hey man, I like this sentence. Insightful! :)
  66. Re: good god!!!![ Go to top ]

    To be fair, from a productivity point of view, Java tools for creating the presentation layer have gotten better. They are almost as good as .NET was a few years ago. However, I haven't looked at .NET in a couple of years and so I'm sure that will have also improved too. You have to ask yourself a question though. Why is RoR gaining in popularity? Is it because J2EE is too cumbersome for doing the simple stuff. Sure Spring, Hibernate are better from a productivity point of view than most of the stuff Sun have supplied in J2EE but if all you want to do is build a front end onto a database, RoR and .NET will do it for you much more quickly. I used to work for a very large organisation (130,000 employees). They moved to a mantra of .NET on the front end, J2EE on the back end for transactional processing because although Java has got much more productive it still isn't close to the productivity you gain with .NET. Sure you can do a lot more with Java then .NET and heaven help you when you stray away from Microsoft's vision of how .NET should be used but .NET beats Java when it come to productivity and in many organisations that is all that counts. For reference, I left that company to join another one where all I do is Java all day and I love it. I spent 4 years working with Microsoft technology and although I think Java gives you more flexibility and allows you to do more, no one can tell me that you aren't more productive with Microsoft's wizards, as long as you stay within the Microsoft walled garden. If you leave that then you run into problems. However many companies are happy to stay within the walled garden because of the productivity that using Microsoft tools brings.
  67. Dumb question ...[ Go to top ]

    Here's my dumb question for everyone. I'm sure everyone has seen the argument "make 90% of what people do brain dead easy." Given that J2EE has a strong bias towards integrations, is there really a 90% that is common "enough" that a general purpose solution would fit? Or maybe a significant percent of the apps built with Java are messy integrations and doesn't fit the 90% model. If that's the case, why is it that people making basic websites that dump database tables to a webpage drag the discussion down the "make the common stuff simple" argument. Since I've done mostly integration stuff the last 7 years, my experience is that integration varies widely, so a general purpose and brain dead solution is impractical. J2EE already contains enough API to handle many of the common integration scenarios. If a project doesn't have to deal with integration across a dozen or more systems, having to deal with all the specs and API will probably feel overly complex. In that case, my bias thinking is that .NET "could" be a good fit. On the otherhand, if an application has to deal with messy integration and 2-phase commits across the internet, .NET would be a poor choice. anyone willing to guess if there's really a "common 90%" or is it just a myth? peter
  68. Re: Dumb question ...[ Go to top ]

    Peter, how do we escape going in circles with one side repeating that everything is too complex and the other side repeating that the complexity is down to the complexity of the task? I think the only way to move this debate forward is to clearly state the problem that a particular feature/technology is supposed to solve and then discuss the various options. I assume that the JCP has done just that in the case of EJB and they have come to the conclusion that it can be done in a simpler way. Now, do you think they have dumped some capability that was there in EJB 2.1 that you need for your integration work? (which is exactly what I do by the way) If the answer is no, then this is a case of true simplification and not a case of dumbing down. It can be done in other areas like packaging and deployment as well. I'm not for dumping a technology just because some people might think it's complicated. But I'm in favour of thinking harder whether a particular solution is the simplest way to solve a particular problem.
  69. things can improve[ Go to top ]

    Peter, how do we escape going in circles with one side repeating that everything is too complex and the other side repeating that the complexity is down to the complexity of the task? I think the only way to move this debate forward is to clearly state the problem that a particular feature/technology is supposed to solve and then discuss the various options. I assume that the JCP has done just that in the case of EJB and they have come to the conclusion that it can be done in a simpler way. Now, do you think they have dumped some capability that was there in EJB 2.1 that you need for your integration work? (which is exactly what I do by the way) If the answer is no, then this is a case of true simplification and not a case of dumbing down. It can be done in other areas like packaging and deployment as well. I'm not for dumping a technology just because some people might think it's complicated. But I'm in favour of thinking harder whether a particular solution is the simplest way to solve a particular problem.
    I completely agree that many "complex" tasks can be made easier, though not necessarily easy. I'll use an example. Say I have to integrate with 4 third party systems, each with it's own database model, object model and services. Part of the complexity of integrating for me is the human aspect of coming to an agreement with a business partner what is "needed" and where problems occur due to incompatability. Say my system allows a customer to be in 3 states: active, suspended, terminated. My business partners have many more states an account can be in. To make things worse, say one of the partners processes account updates in batches manually. Another one does it in real-time and third uses batches and real-time. Now, if I want to do this with J2EE, there's alot of things I can use to solve this problem. To do the same thing in .NET, it's considerably harder and quite painful. I have no proof or data (only first hand experienc) to back up this opinion, but I think for integration scenarios, the requirements vary wildly. Back when I worked on simple websites that simply formatted 1 or 2 tables per page, a simple approach with good defaults makes a lot of sense. I haven't worked on that kind of application in a long time, so I really don't know what people are doing for websites today. clearly, the two camps often end up in an endless debate claiming the other side doesn't understand. my goal isn't that. I'm just questioning why there is this huge disconnect between the two sides and why it is so hard to bridge the gap. that and playing devil's advocate. peter
  70. Re: things can improve[ Go to top ]

    I'm just questioning why there is this huge disconnect between the two sides and why it is so hard to bridge the gap. that and playing devil's advocate.

    peter
    I think part of the problem has been that J2EE was supposed to be the middleware solution where economy of scale and a common nexus would alleviate integration hassles and promote enterprise distributed computing as evidenced by your complex example. For some reason, this sphere of influence leaked into the presentation layer domain where most of the pain people are experiencing is cropping up and where other technologies better address the problem. My question is whether the gap needs to be bridged -- at least from a one solution fits all perspective. I'm not sure why it was extended in the first place. As you put it, J2EE has a pretty robust toolkit for integration/transaction solutions and is where it's strength lies. It's just not as friendly in the presentation layer space and client/server mode. Unfortunately, the argument seems to always be all or nothing with J2EE and to be fair with the other camps as well.
  71. Re: things can improve[ Go to top ]

    I'm just questioning why there is this huge disconnect between the two sides and why it is so hard to bridge the gap. that and playing devil's advocate. peter
    I think part of the problem has been that J2EE was supposed to be the middleware solution where economy of scale and a common nexus would alleviate integration hassles and promote enterprise distributed computing as evidenced by your complex example. For some reason, this sphere of influence leaked into the presentation layer domain where most of the pain people are experiencing is cropping up and where other technologies better address the problem. My question is whether the gap needs to be bridged -- at least from a one solution fits all perspective. I'm not sure why it was extended in the first place. As you put it, J2EE has a pretty robust toolkit for integration/transaction solutions and is where it's strength lies. It's just not as friendly in the presentation layer space and client/server mode. Unfortunately, the argument seems to always be all or nothing with J2EE and to be fair with the other camps as well.
    from a technical perspective, I don't feel it's desirable to bridge the gap. From a human perspective, I'd like to think bridging the gap would be beneficial. I don't like the "be all and end all solution" sales guys pitch. unfortunately, they are necessary evil of life. At the end of the day though, it doesn't matter what framework is used. It's the people building the application that determine whether or not it fails. peter
  72. moving to another world[ Go to top ]

    Such an interesting discussion and responses. I have been developing in MS for well over 12 years. recently while being shipped overseas to retread a flat tire (software analogy), looking down the road I realized that this software was flat on it's face and going no where. The company I was contracted to was a full fledged major-corp-java-c++ company. After months of deciding what to do, they moved the development to java (duh - it's YOUR platform) During the decision months, I had much time reflect on life and it's grand wonders. While I sat there contiplating my next move, I decided to pick up a Java book. After a few weeks I was rolling. Transition Time- If I learned one thing, it's that I realized I was having my hand held during development with MS. When I started to dive into JAVA, Struts, JSP, etc....I found that everything had to be set and in it's correct order and location. Not just throw it anywhere and MS will find it. At first I was kinda frustrated at the complexity of the platform....but then looking back, I was in the same boat with MS. I had to reach the proverbial "top of the hill". Once I got to that point....it all started making sense. Well, now it's 6 months later, and have been developing strong in the JAVA platform. Am I impressed? well to say the least YES! I find it much stronger and more robust for me, able to somewhat handle more than ASP can. I have done the ol' OO development, but I am now having a tendancy to develop more in JAVA for the large scale apps, and leaving the little stuff to MS. Plus I can make JAVA do EXACTLY what I want it to do. Both platforms suit their purpose, both perform as they should. Only the people who truely experienced both sides can honestly discuss this with knowledge. I know where I stand, and I also know where my resume stands :)
  73. moving to another world[ Go to top ]

    Such an interesting discussion and responses. I have been developing in MS for well over 12 years. recently while being shipped overseas to retread a flat tire (software analogy), looking down the road I realized that this software was flat on it's face and going no where. The company I was contracted to was a full fledged major-corp-java-c++ company. After months of deciding what to do, they moved the development to java (duh - it's YOUR platform) During the decision months, I had much time reflect on life and it's grand wonders. While I sat there contiplating my next move, I decided to pick up a Java book. After a few weeks I was rolling. Transition Time- If I learned one thing, it's that I realized I was having my hand held during development with MS. When I started to dive into JAVA, Struts, JSP, etc....I found that everything had to be set and in it's correct order and location. Not just throw it anywhere and MS will find it. At first I was kinda frustrated at the complexity of the platform....but then looking back, I was in the same boat with MS. I had to reach the proverbial "top of the hill". Once I got to that point....it all started making sense. Well, now it's 6 months later, and have been developing strong in the JAVA platform. Am I impressed? well to say the least YES! I find it much stronger and more robust for me, able to somewhat handle more than ASP can. I am now having a tendancy to develop more in JAVA for the large scale apps, and leaving the little stuff to MS. Plus I can make JAVA do EXACTLY what I want it to do. Both platforms suit their purpose, both perform as they should. Only the people who truely experienced both sides can honestly discuss this with knowledge. I know where I stand, and I also know where my resume stands :)
  74. Re: moving to another world[ Go to top ]

    Such an interesting discussion and responses.

    I have been developing in MS for well over 12 years. recently while being shipped overseas to retread a flat tire (software analogy), looking down the road I realized that this software was flat on it's face and going no where. The company I was contracted to was a full fledged major-corp-java-c++ company. After months of deciding what to do, they moved the development to java (duh - it's YOUR platform)

    During the decision months, I had much time reflect on life and it's grand wonders. While I sat there contiplating my next move, I decided to pick up a Java book. After a few weeks I was rolling.

    Transition Time-

    If I learned one thing, it's that I realized I was having my hand held during development with MS. When I started to dive into JAVA, Struts, JSP, etc....I found that everything had to be set and in it's correct order and location. Not just throw it anywhere and MS will find it.

    At first I was kinda frustrated at the complexity of the platform....but then looking back, I was in the same boat with MS. I had to reach the proverbial "top of the hill". Once I got to that point....it all started making sense.

    Well, now it's 6 months later, and have been developing strong in the JAVA platform. Am I impressed? well to say the least YES! I find it much stronger and more robust for me, able to somewhat handle more than ASP can. I am now having a tendancy to develop more in JAVA for the large scale apps, and leaving the little stuff to MS. Plus I can make JAVA do EXACTLY what I want it to do.

    Both platforms suit their purpose, both perform as they should. Only the people who truely experienced both sides can honestly discuss this with knowledge. I know where I stand, and I also know where my resume stands :)
    This is exactly why .NET will never shift Java from its dominant position. Software development is not about technology choices, its about people, and people want to be challenged and in control in their working environment. The more Microsoft 'dumbs down' its .NET development the less satisfaction .NET developers will get from their daily jobs. This leads to de-motivated people which equals crap software produced. I find a similar thing in a pure java environment where I have often been employed (as a contractor) to join a pre-existing team/project consisting mostly of permanent employees to do a 'piece of work' which (as it turns out) is far more interesting than the work going on around me. It is a mangement decision to bring in a contractor and as I sit their I see the motivation of my permanent colleagues falling rapidly as they firefight and bug fix while looking at this contractor who is getting better paid doing more interesting work (work which most of them would be capable of doing). The end result is poor team moral and lowering of motivation and quality of the project/software produced. So if your company wants to choose .NET over Java then I'd suggest this is possibly something you might want to factor in. The happier your staff the better quality of software produced - 'simpler' technologies does not necessarily mean better resulting software (in fact it could mean the opposite). My 2 pence
  75. I've noticed the same trend around here. Not in our organization, because neither is our core technology, but with the developers that left here and went on to do Java during the big Java boom in the late 90s, early 2000s. They actually like C#/.NET better than Java, but (like most programmers probably), don't like the lack of choice. And on the client, it's not really an issue, because they never felt Swing was much of a choice to begin with. The unknown in all of this is whether Mono will ever be able to stack up as hardcore, production level technology. Some of these people have been playing around with in less critical environments. But the thing is that .NET is going to be around for a very long time, so we'll probably see altnernative frameworks arise eventually. Oh, and the other thing that they've commented on that they really like is the easy native interop. Personally, I like the openess around Java, but see the strengths of .NET/C#.
  76. encourage interop[ Go to top ]

    Since .NET is making inroads in your organization, the best way to keep your organization using Java is to promote interoperability strategies so that your team can become aware of how they can retain their Java investment even when doing .NET development. There are numerous interop strategies, including Web services interop, bridging technologies, and others. We provice an interop product (JNBridge), but there are a number of others, including several that are open source. It would probably be a good idea to start with one of the several interop books that are out there, including those by Simon Guest, Peter Laudati (both of Microsoft), Dwight Peltzer, and the new book by Marina Fisher from Sun.
  77. I think Joel Spolsky put it best in his blog at http://www.joelonsoftware.com/articles/APIWar.html: "...technically. .NET is a great programming environment that manages your memory and has a rich, complete, and consistent interface to the operating system and a rich, super complete, and elegant object library for basic operations. And yet, people aren't really using .NET much. Oh sure, some of them are. But the idea of unifying the mess of Visual Basic and Windows API programming by creating a completely new, ground-up programming environment with not one, not two, but three languages (or are there four?) is sort of like the idea of getting two quarreling kids to stop arguing by shouting "shut up!" louder than either of them. It only works on TV. In real life when you shout "shut up!" to two people arguing loudly you just create a louder three-way argument." "So now instead of .NET unifying and simplifying, we have a big 6-way mess, with everybody trying to figure out which development strategy to use and whether they can afford to port their existing applications to .NET. No matter how consistent Microsoft is in their marketing message ("just use .NET—trust us!"), most of their customers are still using C, C++, Visual Basic 6.0, and classic ASP, not to mention all the other development tools from other companies. And the ones that are using .NET are using ASP.NET to develop web applications, which run on a Windows server but don't require Windows clients"
  78. And yet, people aren't really using .NET much.
    Nonsense
    But the idea of unifying the mess of Visual Basic and Windows API programming by creating a completely new, ground-up programming environment with not one, not two, but three languages (or are there four?) is sort of like the idea of getting two quarreling kids to stop arguing by shouting "shut up!" louder than either of them. It only works on TV. In real life when you shout "shut up!" to two people arguing loudly you just create a louder three-way argument."
    Except your analogy doesn't make sense. You do realize that this isn't 2001 and they've already done it, don't you? Maybe this stuff is complicated for you, but not for other people. It's as simple as "We're going to use C# for this project", or "we're going to use VB.NET for this project.
    No matter how consistent Microsoft is in their marketing message ("just use .NET—trust us!"), most of their customers are still using C, C++, Visual Basic 6.0, and classic ASP, not to mention all the other development tools from other companies. And the ones that are using .NET are using ASP.NET to develop web applications, which run on a Windows server but don't require Windows clients"
    Do you even know that C/C++ can be compiled to .NET? In any case, .NET is the future of Windows programming whether people like it or not. There's just no getting around it. And since desktop linux never took off, the client will be .NET and the browser for simpler tasks.
  79. Do you even know that C/C++ can be compiled to .NET?
    Utter nonsense. .NET (the Micosoft clean-room JVM) supports Java (albeit slightly broken and renamed as C#) and two slightly syntactically-disguised versions of Java called VB.NET and C++.NET. As has been pointed out many times by people who actually use VB and C++, .NET supports neither VB nor C/C++. Never has. Never will. Cannot. (It is a nice research version of Java, though. ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  80. thanks for the laughs[ Go to top ]

    I can always count on cameron for a good laugh. if only my jokes were half as funny. good thing I don't tell jokes for a living. peter
  81. Utter nonsense. .NET (the Micosoft clean-room JVM) supports Java (albeit slightly broken and renamed as C#) and two slightly syntactically-disguised versions of Java called VB.NET and C++.NET.
    Yes, C# is "broken" that's why Sun has to use it for ideas for the next revision of their dumbed-down Java.
    As has been pointed out many times by people who actually use VB and C++, .NET supports neither VB nor C/C++. Never has. Never will. Cannot.
    Yes, and that's why Quake II had to be rewritten in another language. Not. http://www.codeproject.com/managedcpp/quake2.asp
    (It is a nice research version of Java, though. ;-)
    Exactly, Microsoft does the research and Sun copies.
  82. Utter nonsense.

    .NET (the Micosoft clean-room JVM) supports Java (albeit slightly broken and renamed as C#) and two slightly syntactically-disguised versions of Java called VB.NET and C++.NET.


    Yes, C# is "broken" that's why Sun has to use it for ideas for the next revision of their dumbed-down Java.


    As has been pointed out many times by people who actually use VB and C++, .NET supports neither VB nor C/C++. Never has. Never will. Cannot.


    Yes, and that's why Quake II had to be rewritten in another language. Not.
    http://www.codeproject.com/managedcpp/quake2.asp

    (It is a nice research version of Java, though. ;-)


    Exactly, Microsoft does the research and Sun copies.
    ... http://www.bytonic.de/html/jake2.html And God said let's the flame war begin!
  83. ... http://www.bytonic.de/html/jake2.html And God said let's the flame war begin!
    Haha, they rewrote the entire thing in Java. I guess someone might be rewriting it in Ruby too, or Python, or BrainF*ck, or.. Wake me up when someone is compiling C++ (any kind of C++) to the JVM.
  84. ...
    http://www.bytonic.de/html/jake2.html

    And God said let's the flame war begin!


    Haha, they rewrote the entire thing in Java. I guess someone might be rewriting it in Ruby too, or Python, or BrainF*ck, or..

    Wake me up when someone is compiling C++ (any kind of C++) to the JVM.
    Why would they? You know Java supports this thing called system integration. But if you want to program using a totally different language there is always JRuby, JPython, Groovy or BeanShell.
  85. Why would they? You know Java supports this thing called system integration. But if you want to program using a totally different language there is always JRuby, JPython, Groovy or BeanShell.
    There's this thing called code-reuse. Something Sun doesn't seem to understand, that's why they inflicted JNI on everybody. Maybe Sun will get wise and look at .NET and pinvoke for some inspiration for Dolphin.
  86. Why would they? You know Java supports this thing called system integration.

    But if you want to program using a totally different language there is always JRuby, JPython, Groovy or BeanShell.


    There's this thing called code-reuse. Something Sun doesn't seem to understand, that's why they inflicted JNI on everybody.

    Maybe Sun will get wise and look at .NET and pinvoke for some inspiration for Dolphin.
    Ok as you wish. Why are you hanging out on a enterprise Java web site again?
  87. Ok as you wish. Why are you hanging out on a enterprise Java web site again?
    I wasn't issued my TSS pom poms, so I'm unable to circle the wagons with you.
  88. Ok as you wish. Why are you hanging out on a enterprise Java web site again?


    I wasn't issued my TSS pom poms, so I'm unable to circle the wagons with you.
    Yeah and having the "Java is evil, .Net is God" attitude is better. I guess it's probably my paranoid personality acting again. Anyway, I won't turn this into a personal debate so I'm done here. I shouldn't get into those religious debates in the first place. Have fun!
  89. Yeah and having the "Java is evil, .Net is God" attitude is better. I guess it's probably my paranoid personality acting again. Anyway, I won't turn this into a personal debate so I'm done here. I shouldn't get into those religious debates in the first place. Have fun!
    Yeah, it is your paranoid personality, but you're not alone. Cameron Purdy has to bust out his standard "it's a nice research language" line everytime the Java inferiority complex hits too close to home. I'm not impressed by either C# or Java(the language). Both platforms have their strengths and weaknesses. .NET has the technical superiority, but Java has a better crossplatform footprint. In my ideal world, I would have something like Nemerle running on top of the JVM with great IDE support. But Sun seems to have no interest in anything except Java(the language). Maybe Dolphin will change things.
  90. ...[ Go to top ]

    We know the discussion has devolved to its lowest when someone like Carmack needs to come here and say "Um... no, but have a nice day."
  91. [..] Sun doesn't seem to understand, that's why they inflicted JNI on everybody. Maybe Sun will get wise and look at .NET and pinvoke for some inspiration for Dolphin.
    See? We don't disagree on everything ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  92. Wake me up when someone is compiling C++ (any kind of C++) to the JVM.
    Wake up! The Jazillian product has been around for years: http://www.jazillian.com/ More interesting, I spoke with the guys at Excelsior, the company that makes Jet: http://www.excelsior-usa.com/jet.html FWIW - They've been doing work with Java on mobile phones where they compile the C codecs for multimedia into Java, because the Java processors in the phones run the multimedia much faster than the "native" (I'm assuming ARM-based) processors run the C. So yes, for these apps, they do compile C (in this case not C++) into Java. Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  93. Jazillian is cool[ Go to top ]

    Having used jazillian and talked with the guy who created jazillian, it's a good product. if I ever need to translate C to Java, I would definitely use it. peter
  94. Wake up! The Jazillian product has been around for years: http://www.jazillian.com/ More interesting, I spoke with the guys at Excelsior, the company that makes Jet: Yeah, that's Andy Tripp's project. I'm sure it's a nice tool (never used it), but in no way can you compare translating a relatively simple language like C into Java source code, to the effort it takes to compile C++(including STL I presume) to MSIL. It's interesting that you bring up Excelsior because it would have been real nice to have produced something like this (years ago), with the option of installing a small runtime and on-demand component downloading. http://bugs.sun.com/bugdatabase/view_bug.do;:WuuT?bug_id=4267080 So sad, that "bug" was filed in '99 and it never happened.
  95. couple of clarifications[ Go to top ]

    Couple of corrections and clarifications for you... Peter Lin said:
    The old build tool with VS.NET 2003 was god aweful. Comparing ANT or NANT to the old build tool is rather unfair to MS. I hear the new team system tools are much better than the old one, but I haven't used it. considering how much a full VS.NET license costs, I can't afford it. Open source java fits my price point much better :)
    As Sanchez pointed out, you get MSbuild with the express (Free) versions of Visual Studio. MSBuild comes with the (also free) .NET SDK, too. ------------------ Cameron Purdy wrote:
    The real idiotic decision by Microsoft was to make it incompatible with Java, which means that developers are typically left with "either / or" choices. In the end, it will be the failure of .NET, because it's an all-or-nothing gambit (and I believe it provable that Microsoft cannot win "all").
    I'm not clear on what you mean by ".NET is an all-or-nothing gambit." Maybe this is obvious, but in case it isn't, there's nothing in the .NET license that says "by using .NET you promise to never develop another line of code in Java again." Also there are numerous posters on this thread who have reported that their organizations use both Java and .NET. I'm sure I misunderstood your point somehow. An alternative view: If you look at the time and effort Microsoft has put into helping define XML and web services protocols - all dedicated to heterogeneous interoperability - and the time and effort Microsoft put into supporting those protocols in .NET, then you might logically conclude that Microsoft recognizes that heterogeneity is here to stay, and the MS development platform had better support it. Or, you might look at that information and still somehow conclude that .NET is an "all-or-nothing gambit" by Microsoft, but that seems contrary to the facts. Like I said, maybe I misunderstood the point. ------------------ Daniel Selman reported that he had numerous challenges building an outlook add-in. PIAs - if you want to support multiple versions of Office, don't use PIAs. Memory management - yeap, you still need to do that. sorry bout that. No way to run multiple versions of the CLR in a single process - yeap, this is a fundamental design point. But if you compile code against .NET 1.1, it will run against .NET 2.0. Outlook object model is complex - yes. None of these issues are insurmountable. Developers tend to learn this on the first add-in project, and then they move on. ------------------ Purdy:
    .NET (the Micosoft clean-room JVM) supports Java (albeit slightly broken and renamed as C#) and two slightly syntactically-disguised versions of Java called VB.NET and C++.NET.
    Purdy, you seemed like such a mild-mannered, level-headed software guy when you presented on distributed caching at JavaOne. When you talk about .NET it's as if reason flies out the window. ;) C# is a standard language. (see ECMA and ISO). It is similar to Java syntax, and you might even say it is derivative, but they are clearly two different languages. You can call it broken if you like, but a more accurate term might be "different." I won't argue opinions though. C++.NET is not a language. For a while Microsoft was attaching the ".NET" suffixe to everything, including C++. This term is no longer used by Microsoft. The current term Microsoft uses to describe the .NET-enabled C++, is "C++ with managed extensions." If you write a C++ app and compile with Microsoft's C++ compiler, you get good-old C++ down-to-the-metal semantics. But, it is also possible to write code in C++ that runs within the CLR, and gets the CLR's memory management and so on. It is still C++; it is not a variant of Java, syntactically disguised. To get this feature, you have to use a special code scope, and a special command-line compiler switch (or checkbox in the IDE). C++ with the managed extensions is definitely not Java. (All this was true when Microsoft called it "C++.NET", too) Just for the record, .NET does support a Java syntax as well, via the J# language. But of course J# is based on a back-rev of Java syntax and so does not support things like generics, foreach, autoboxing, and other language advancements that came in 1.5/5.0. I guess you will call J# "broken" as well, or maybe something more derogatory. The reason behind J# is to bring forward all the J++ developers, since Microsoft has sunsetted the J++ toolset. J# supports J++ syntax completely - so from that perspective it is not broken. If you want Java 5.0 syntax, then J# is definitely not it. --------------------- Steve Zara wrote:
    ... Microsoft has a history of changing direction in terms of development languages and tools and leaving many developers behind. Some examples: Object Pascal (their attempt to compete with Turbo Pascal). Microsoft Fortran. PenWindows. Visual Basic 6 (a migration to VB.NET is not trivial).
    "Many developers" is sort of vague, and surely there were developers who used Object Pascal, MS Fortran, and PenWindows, but probably not "many" in the same way that there are "many" VB6 developers. Like Millions. Migration from VB6 to VB.NET is not trivial, you're right. You say Microsoft has a history of changing direction, and it's hard to argue that. Microsoft is continuously trying to develop and release new stuff for developers. Just for the record, VB6, the developer tool, was introduced in September 1998, as part of Visual Studio 6.0. The end-of-mainstream support date for VB6 was March 2005. That's 6.5 years of support, which is much longer than any version of any Java tool that I know of. (There is extended support available for a fee, until March 2008.) To give you some perspective, based on the javaworld.com archive I found, I believe the IBM Java tool at the time VB6 was released, was called "Visual Age for Java 1.0". How long had VAJ 1.0 been out of support, by March 2005? In the interim, IBM shipped VAJ 2.0, 3.0, 3.5 and 4.0; then changed brands and shipped WebSphere Studio 4.0, then WebSphere Studio 4.0 again (same name, different tool), then WebSphere Studio 5.x, and Rational App/Web Developer 6.x. Which of those are still supported? Would you say that "IBM has a history of leaving developers behind"? Sun's tool in spring 1998 when VB6 shipped was called "Sun Java Workshop 2.0". Was anyone still using *that* in 2005? In 1998, the other big Java tools were Symantec Cafe, Borland JBuilder 1.0, and and .... who can remember this ? help me out here. Were any of those things still supported in early 2005? http://www.javaworld.com/javaworld/jw-04-1998/jw-04-visual-ides.html I guess I cannot argue with your characterization of Microsoft's release of VB.NET and subsequent end-of-(mainstream)-support for VB6 as "leaving developers behind": there are lots of VB6 developers, and they need to learn new things to productively use VB.NET. But consider that situation relative to other tools vendors. Six years may not be enough for you - that's a fair statement to make - but six years is better than all the other mainstream developer tools I know of. If 6.5 years of support is "leaving developers behind" then how would you describe the situation with Sun Java Workshop 2.0 or IBM Visual Age for Java 1.0 or Symantec Visual Cafe? I work for Microsoft. Yeah, I know this is a Java booster site. I'm not trying to rain on your parade. Just trying to inject some balance into the discussion. As you were...
  96. Nice post Dino, I wonder if you could speak to the issue of complexity and capability. It seems that a lot of people on this board say that .NET is good for simple CRUD applications but Java is better for Enterprise apps. It is also often stated that while .NET may be more productive, Java can do a lot of things that .NET cannot. Other than run on multiple OSs (Mono notwithstanding), I cannot think of anything that Java can do that .NET cannot. Can you give your input? Thanks, Trevor
  97. Nice post Dino, I wonder if you could speak to the issue of complexity and capability. It seems that a lot of people on this board say that .NET is good for simple CRUD applications but Java is better for Enterprise apps. It is also often stated that while .NET may be more productive, Java can do a lot of things that .NET cannot. Other than run on multiple OSs (Mono notwithstanding), I cannot think of anything that Java can do that .NET cannot. Can you give your input? Thanks, Trevor
    Say I want to compile a XML Schema so that when an object attribute is set, it notifies a list of listeners. In .NET 1.0/1.1 XSD.exe, it generates C# classes that do not support that capability. I believe even .NET 2.0 XSD.exe does not support that capability. I have a comparison of the XML Schema compiler I wrote named dingo vs XSD (http://dingo.sourceforge.net/comparison.shtml). Clearly I am bias, since I think VS.NET is lacking. Another area where VS.NET 1.0, 1.1 and 2.0 are very weak is mapping different XML schemas to a single object model. The best example I can think of is what JiBX does. In a previous job, we needed this capability. Since MS didn't provide that kind of tool in 1.0/1.1, we had to build one. I suggested the developer in charge of the task port JiBX, but instead they wrote some piece of junk. Does 2.0 offer these kinds of capabilities? I haven't kept up, so I don't know if this area has improved. peter
  98. Thanks for the reply. I will look into what is supported in 2.0 in this regard. But just to clarify, are you comparing what is natively supported in .NET 2.0 and JDK 1.5 or what is available via third parties? It sounds like you used a third party vendor for Java to acheive your result. Now granted that might be an argument for Java as to the abundance of such support, but it doesn't speak directly to the question of what can and cannot be done in either framework.
  99. Thanks for the reply. I will look into what is supported in 2.0 in this regard. But just to clarify, are you comparing what is natively supported in .NET 2.0 and JDK 1.5 or what is available via third parties? It sounds like you used a third party vendor for Java to acheive your result. Now granted that might be an argument for Java as to the abundance of such support, but it doesn't speak directly to the question of what can and cannot be done in either framework.
    Good point. In java, I've used castor to achieve the same goal. Since most .NET centric shops use only MS tools, it might still be a valid comparison. Though it's probably an unfair comparison, since people mix and match different tools with a java platform. If I include all the OSS .NET stuff in the comparison, than .NET and Java platform (not necessarily j2ee) are pretty even. Over all, my bias perspective is that Java has much more tools for integration scenarios than .NET. The times I've tried to convince people to use third party .NET tools, it was met with negative response from the other developers and management. For example, I tried to convince the team to use NAnt, when the stock build tool with VS.NET 2003 fell apart and we couldn't get it to work with our setup. Like wise, I tried to convince the team to use a third party ORM tool, since we had to handle third party models and data, but the resistance quickly shot that down. I hate to say it, but I've seen many cases where the response to third party tools was "We should only use MS tools, since MS will either knock them out or make a better version." Ignoring that kind of (breain dead) thinking and looking at the actual tools, the two platforms are fairly even. Each has it's strengths and weaknesses. peter
  100. The times I've tried to convince people to use third party .NET tools, it was met with negative response from the other developers and management. For example, I tried to convince the team to use NAnt, when the stock build tool with VS.NET 2003 fell apart and we couldn't get it to work with our setup.

    Like wise, I tried to convince the team to use a third party ORM tool, since we had to handle third party models and data, but the resistance quickly shot that down. I hate to say it, but I've seen many cases where the response to third party tools was "We should only use MS tools, since MS will either knock them out or make a better version."

    Ignoring that kind of (breain dead) thinking and looking at the actual tools, the two platforms are fairly even. Each has it's strengths and weaknesses.

    peter
    I agree that that is a brain dead approach and have encountered that numerous times during my Delphi-centric days. I always found it foolish since there were so many excellent third party libraries for Delphi. I've not found that to be the attitude as much with .NET, but I'm sure it is probably more that way than in the Java world. There are a number of OR mapping tools for .NET, but I will concede that for simpler applications, the "MS" way often works well enough and that is probably why the reputation sticks. BTW, I took a brief look at Dingo. Looks pretty cool. I haven't needed (or maybe I did but didn't know it) such a tool, but you've peeked my interest. Most of the XML mapping I've done has been dataset related. I've also found the .NET XML object serialization to work fairly well, but that is simpler it seems than the problem you are addressing with schema compilers. More for me to learn I guess.
  101. The times I've tried to convince people to use third party .NET tools, it was met with negative response from the other developers and management. For example, I tried to convince the team to use NAnt, when the stock build tool with VS.NET 2003 fell apart and we couldn't get it to work with our setup. Like wise, I tried to convince the team to use a third party ORM tool, since we had to handle third party models and data, but the resistance quickly shot that down. I hate to say it, but I've seen many cases where the response to third party tools was "We should only use MS tools, since MS will either knock them out or make a better version." Ignoring that kind of (breain dead) thinking and looking at the actual tools, the two platforms are fairly even. Each has it's strengths and weaknesses. peter
    I agree that that is a brain dead approach and have encountered that numerous times during my Delphi-centric days. I always found it foolish since there were so many excellent third party libraries for Delphi. I've not found that to be the attitude as much with .NET, but I'm sure it is probably more that way than in the Java world. There are a number of OR mapping tools for .NET, but I will concede that for simpler applications, the "MS" way often works well enough and that is probably why the reputation sticks. BTW, I took a brief look at Dingo. Looks pretty cool. I haven't needed (or maybe I did but didn't know it) such a tool, but you've peeked my interest. Most of the XML mapping I've done has been dataset related. I've also found the .NET XML object serialization to work fairly well, but that is simpler it seems than the problem you are addressing with schema compilers. More for me to learn I guess.
    Sometimes Java world can suffer from the "too many choices" symdrome. For example, a friend recently came across an issue where they had to integrate with a webservice written in .NET 2.0. The model contained an object that used xs:any. Well, that ended up causing problems because bea's webservice stack didn't handle it correctly. I suggested he try other java toolkits like JWSDP, axis and castor, but none of them were able to handle xs:any type correctly. For comparison, when I needed castor like capabilities, I had zero choice in .NET including third party tools. My guess is that very few people needed to do these kinds of things. .NET's XML serialization stuff is nice, but the XSD.exe tool is rather lame. Considering that it took me 2 months of coding in my free time to write dingo, I'm rather shocked XSD.exe took so long for MS to write. Even .NET 2.0 XSD.exe has limited functionality. AFAIK, .NET 2.0 XSD does not have plugin capability, nor does it handle a lot of the optional XML Schema stuff. When I got an preview release of VS.NET 2005, it still wasn't able to compile Xmlschema.xsd which is the definition of XML Schema in XSD format. peter
  102. notification listeners[ Go to top ]

    That's easy, make the attributes properties such that the setters make calls (possibly on different thread) to listeners. You can create these schema classes via WSCF 0.51/0.6 or modify the ones .Net creates in .Net 1.1. .Net 2.0's xsd.exe gives you the option to create properties.
  103. Re: notification listeners[ Go to top ]

    That's easy, make the attributes properties such that the setters make calls (possibly on different thread) to listeners. You can create these schema classes via WSCF 0.51/0.6 or modify the ones .Net creates in .Net 1.1. .Net 2.0's xsd.exe gives you the option to create properties.
    What would be the point of modifying the XSD generated code by hand? If someone is going to hand code the class, then skip XSD. With castor, the compiler generates java classes with java beans support. With dingo, I have a sample plugin that can generate listener support. No manual changes needed. I don't know the reason why microsoft doesn't support these kinds of scenarios, maybe it's because XSD.exe is poorly designed and can't support this kind of functionality without a major rewrite. Even XSDObjectGen by microsoft does not support pluggable code generators. Having written dingo to support these types of integration related issues, .NET does not have good support for this kinds of problems. XSD does a very specific thing and keeps things super simple. That is the primary strength in my bias opinion. Could microsoft make XSD a bit more flexible and better suited for other scenarios? From a technical perspective, Microsoft could, but they chose not to. My original reason for writing Dingo is that I needed to generate different implementations of the same model. One version with listeners for GUI apps. Another version for Data access layer. A third for business logic and other related functionality. Going with a pluggable approach was my solution to this specific problem. Microsoft does not support this kind of functionality in their tools. That's not necessarily a good or bad thing. It's just what MS tools provide. peter
  104. Re: notification listeners[ Go to top ]

    So, what you are saying is that you used the same object for your GUI, Business, and Data Access Layer? That's sounds a little too tightly-coupled. Do you recompile everything when your business logic classes need a new property?
  105. Re: notification listeners[ Go to top ]

    So, what you are saying is that you used the same object for your GUI, Business, and Data Access Layer? That's sounds a little too tightly-coupled. Do you recompile everything when your business logic classes need a new property?
    the same model, but not the same concrete classes. obviously there's coupling, but using a JAXB style, the application code uses the interfaces. whereas if one uses XSD generated code, it's coupled to the concrete class directly. the schema compiler generates code with the necessary hooks the framework needs. like a GUI framework that needs listener. on the serverside, there might be a data cache framework for updating and saving data. peter
  106. Re: I can think of a couple of areas[ Go to top ]

    Nice post Dino,

    I wonder if you could speak to the issue of complexity and capability. It seems that a lot of people on this board say that .NET is good for simple CRUD applications but Java is better for Enterprise apps. It is also often stated that while .NET may be more productive, Java can do a lot of things that .NET cannot. Other than run on multiple OSs (Mono notwithstanding), I cannot think of anything that Java can do that .NET cannot.

    Can you give your input?
    Thanks,
    Trevor


    Say I want to compile a XML Schema so that when an object attribute is set, it notifies a list of listeners. In .NET 1.0/1.1 XSD.exe, it generates C# classes that do not support that capability. I believe even .NET 2.0 XSD.exe does not support that capability. I have a comparison of the XML Schema compiler I wrote named dingo vs XSD (http://dingo.sourceforge.net/comparison.shtml). Clearly I am bias, since I think VS.NET is lacking. Another area where VS.NET 1.0, 1.1 and 2.0 are very weak is mapping different XML schemas to a single object model. The best example I can think of is what JiBX does.

    In a previous job, we needed this capability. Since MS didn't provide that kind of tool in 1.0/1.1, we had to build one. I suggested the developer in charge of the task port JiBX, but instead they wrote some piece of junk. Does 2.0 offer these kinds of capabilities? I haven't kept up, so I don't know if this area has improved.

    peter
    Yes it does with Frmework 2.0. You can use XSD.exe to generate types that support obesrvable properties which when changed raise notifications to consumers. You could do this even with 1.1, but it required some hand coding and was not automated.
  107. I wonder if you could speak to the issue of complexity and capability. It seems that a lot of people on this board say that .NET is good for simple CRUD applications but Java is better for Enterprise apps. It is also often stated that while .NET may be more productive, Java can do a lot of things that .NET cannot. Other than run on multiple OSs (Mono notwithstanding), I cannot think of anything that Java can do that .NET cannot.
    Yes, some people say Java is more powerful. Few people give concrete examples. E. Gault said:
    I find it much stronger and more robust for me, able to somewhat handle more than ASP can.
    no examples. Neil Bartlett wrote:
    On the other hand, if you want to do something that Microsoft did NOT anticipate you wanting to do, then things suddenly become inordinately hard, or literally impossible.
    no examples. Related, but somewhat different, is the observation that .NET is limited. Victor Yushenko wrote:
    It's hard to do anything that just a tad off mainstream...
    One example, which I don't really understand. Peter Lin:
    .NET framework is great if you do exactly how MS does it. If not, it becomes a royal pain.
    One example, which I don't really get. Here's my list of things that are harder in .NET than in Java: Clustering
    Victor Yushenko pointed out that clustering is stronger in Java than in .NET. I think that is fair to say. WebSphere and WebLogic app servers include distributed data caches, which can be deployed across clusters. They have administrative consoles that allow administration of apps on clusters, rather than apps on machines. Windows Server doesn't do these things. (Also there are more 3rd party cache product options for Java than for .NET). java.lang.reflect.Proxy
    You can do this in .NET, but you have to burn a base class to do it. (ManagedByReferenceObject). Zip
    .NET lacks a built-in class for handling zips. You have to go to 3rd party classes, or to the J# runtime to get this. I cannot think of anything else (aside from running on zOS, etc) that you can do in Java that is not practically possible in .NET. Turing machines and all. But even "practically speaking". I'm sure someone will add to the list. --------------------------------- Not on my list: Anything not mainstream.
    Examples? I guess you could say the XML serialization thing that Peter Lin described is an example, but JAXB doesn't do this either, and Peter's solution (writing his own framework) didn't seem that hard. Another way might have been to write the business classes any way you want, and then implement IXmlSerializable. Victor mentioned using a Frameset in a page generated by ASPX, as an example of stuff that gets hard "off the beaten path." I confess I do not understand the issue. It's true you have to manage the seams between Frames and the ASP.NET model, but I don't think that combination presents challenges that are distinct from the challenges presented by Frames and JSF or Frames and JSP. Maybe I am wrong. For the record, I hate Frames. Object-Relational Mapping
    This used to be the #1 thing people mentioned that differentiated Java from .NET. Turns out EJB isn't as easy as people want it to be, and the lighter-weight approaches that are more popular today, work in Java *and* .NET, and the 3rd-party .NET tools are much more mature. So this is no longer a distinguishing factor. Distributed Transactions
    Ranjiva Prasad said in this thread, "if you want to create a highly scalable, highly available application that needs to update numerous databases and legacy systems in the same transaction then use J2EE." My first answer to that is, if that's what you want to do, change your mind. Distributed transactions are a really powerful tool, but going to 3 distributed participants is really hazardous, and should only be done in special circumstances. (Geoff Hendrey also pointed out above that this scenario is a 0.1% of apps). Having said that, if you want a distributed transaction, you can do it in .NET, in a variety of ways. .NET includes System.Transaction api, which is something like JTA, except System.Transactions is accessible from any app, not just a server-side app. So .NET can do "app managed transactions" (aka bean-managed transactions, without necessarily requiring the bean, or server-side component). .NET can also do component-based declarative transactions. .NET relies on the MSDTC for the underlying transaction coordination, and it's pretty fast, and reliable. large scale systems
    .NET runs on 64-bit servers and .NET apps can access all of the 64-bit memory. In our tests this mostly makes sense when maintaining a really large cache. .NET also scales out; you can run your apps spread across farms. shared infrastructure
    Most enetrprises I know of have a shared hosting environment for their J2EE and .NET apps - a managed cluster of servers into which apps get deployed. There is no need to have a dedicated box per app. This keeps operational and capital costs low. high performance message queueing
    MSMQ is built-in to Windows (free!**). You can utilize it from within any .NET app, transactionally or not (with or without MSDTC coordination). I know Java also has this, which is why I am including this on the list of things that does not distinguish .NET from Java. By the way, you can also get to MSMQ from Java. policy-based security
    Both .NET and Java have it. SSL stream support, encryption, non-blocking I/O, etc etc Both have this. Servlet filters are the equivalent of ASP.NET handlers. Generics. and so on. This list could probably get pretty long, so I'm just going to stop here. --------------------------------- Flipping the question on it's head, there are some things in Java where if you go off the beaten path, woe be unto you. Whereas, those same things in .NET are easy. For example: Annotations
    .NET attributes came before Java annotations, so you would think the Java version would be at least as simple, powerful and useful as the .NET variant. Alas, no. Annotations are formalization of Xdoclet, apparently - a build time thing. In .NET, attributes are a runtime thing. if you decorate a class with a custom attribute, your attribute code can and will be invoked at runtime, when that class is used. There is no need to use apt or some other pre-compiler to generate more code. Class versioning
    In Java, everything is dependent upon the classpath and the mysteries of the classloader. If you put log4j-1.2.7.jar in yourclasspath, and the app is built for log4j-1.2.8, then who knows what will happen? It will certainly *try* to run. It *might* work for a while, and then poof! This is especially pernicious when dealing with XML parsers, since every library seems to use a different version. Elsewhere, I ranted on this previously. In .NET, this does not happen. Every class is strongly-named, versioned and signed, and apps run against what they're built against. If the app gets deployed without the library (it's a DLL, but equivalent to a jar in this discussion) it was built against, it fails to start. This is sort of a misnomer, because, it isn't "off the beaten path" to have a tangled hierarchy of library dependencies in a big app. It is the beaten path. Every large app has it. But somehow it is still hard in Java. Code generation
    .NET has a CodeDom, which is a programming model for generating classes at runtime. It's a bit of a niche, but really useful when you need it. Calling native code
    Sure, you can do this in both. Java has JNI. .NET has p/Invoke. The latter is much, much simpler. It's almost as if the designers of Java didn't *want* developers to call C++, if you can imagine that. ;) --------------------------------- Then there area bunch of little things, that, added up, make up the "things are just simpler in .NET" observation: Delegates
    you gotta do a bunch of pushups in Java to accomplish the same thing. Way way back (1998), Sun thought the delegates in J++ were noteworthy enough to publish a paper on why real Java doesn't have delegates (http://java.sun.com/docs/white/delegates.html), going so far to say "It is unlikely that the Java programming language will ever include this construct." (Microsoft responded, http://msdn.microsoft.com/archive/en-us/dnarvj/html/msdn_deltruth.asp) I think BEA's Beehive thing had some nice eventing constructs. And if I am not mistaken, I think the "Java futures" talk at JavaOne 2006 mentioned something about a delegate-style construct, either in Java 6 or 7. Partial Classes
    Partial classes means I can define part of a class in one module, and the rest "somewhere else", in another module. they both have to be compiled at the same time, to produce usable bytecode (MSIL in .NET-speak). Most people don't actually see this explicitly; instead this feature is strongly leveraged by tools. Tools segregate generated code from custom code; developers can extend or modify generated classes, without worrying about their changes getting overwritten, and without having to re-port their changes, on the next generation cycle. metadata
    JEE 5 is aiming to fix this, by eliminating much of the xml goo you have to wade through to dpeloy an app - sensible defaults, and a hierarchical config inheritance model will help. But .NET has had this since day 1. Database connection pools
    How big is your JDBC connection pool? Does anyone really care? And who is the right person to decide how big the pool should get? .NET has auto-creating database connection pools, with automatic sizing. in fact, this philosophy is sort of endemic to the entire architecture. If at all possible, Microsoft wants to eliminate the requirement to touch a knob. Not to eliminate the tuning knob, just to eliminate the requirement that you must use it. connection pools are an example. Heap sizes are another. transaction timeouts. essentially there are sensible defaults for these things and you override them if you need to. most people don't override them, and many don't even know the knobs exist. It's sort of like the car with a manual choke control inside the cockpit, versus the car that adjusts the choke automatically via engine management computer. You could adjust the choke manually, but... why would you want to? the computer is better at monitoring the inputs and making the right decision. ASP.NET used to be on this list - but now JSF is available, with a nice model that is similar. ASP.NET still has many more controls than JSF, all shipped in the tool. In practice, then I think ASP.NET is still easier but will leave it off the list just in case. --------------------------------- But, by far, I think the biggest difference is the one people have already pointed out. Choice versus not. Many options versus few options. It's not that Microsoft wants to eliminate choice. Instead MS wants to maximize productivity. It's good for the business if the developer gets the job done more quickly. It's not good for the business if the developer spends 2 weeks analyzing which persistence framework to use. Choice is not bad by itself, but too much choice... - you know, the zen thing. In .NET, if you're building a web app, then essentially you're going to use IIS. Sure you could host your own http server in C# or VB.NET code, but why would you? So you use IIS, and you get the security model, the process and activation model, the management model of IIS. In Java, there are 5 different viable options, and each one is a little different. does the difference make up for the cost required to analyze the decision? *that's* the question, isn't it?
  108. Peter Lin:
    .NET framework is great if you do exactly how MS does it. If not, it becomes a royal pain.
    One example, which I don't really get.
    I'll try to elaborate on this a bit. Back in 2002-2003 I was on a project building financial applications using .NET. One thing I wanted to do is send messages from the database, like using Java triggers to send JMS message. In SqlServer 2005, the feature exists now. Back in 2002, the only options was to either poll the database or use the built in mechanisms. Neither are scalable in my bias opinion, because in this case, there's a constant stream of insert and update queries. Every time I have to poll the database, it impacts the database server. Another area is code generation. Although it took me 2 months of free time to write it, I wouldn't say it's easy. to give some perspective. by the time I wrote my own XML Schema compiler, I already had lots of experience with JAXB, and Castor. It also helped that I already had a decent understanding of compilers and was comfortable writing parse trees with JavaCC. When I worked with .NET, someone else was given the task of "extending XSD" to add custom capabilities like listeners. It took several months of fulltime work to get around the crap. by the time I stared Dingo, I already knew that route would be a complete waste of time. As for partial classes, I think it's a horrible idea. I had an user ask for it, but I politely suggested he fork the code. In terms of scalability, I'm pretty sure MSMQ doesn't get any where near IBM MQSeries. Atleast not from the work loads we used to benchmark it. The last time I looked, MSMQ doesn't provide the same level of fault tolerance and clustering as MQSeries or even ActiveMQ. To put things in perspective though, most people don't need that kind of performance. I think .NET attributes are better than Java annotations. Frankly, it's stupid that SUN didn't add that sooner, so I thank MS for kicking SUN in the pants on that one. I'm not a fan of delegates and the extra work it requires. The system I had to work required creating a pool of engines to do heavy work. In .NET the optimal ration was 2 engines per CPU. In java, I could load up 10 engines per CPU. There is a significant difference in the threading model from first hand experience. I'm not an expert on .NET, so I'm sure someone who is an expert could get similar performance from .NET threads. I went as far as to use a third party threadpool implementation since the default Thread pool in .NET had a max of 25. I needed to be able to create a pool of 50-200 threads. We eventually worked around it by not having a threadpool, but it was a pain and took a lot of time. Despite all that, C# is a good language and .NET is productive. For what I was trying to build, it was horrible inefficient and unproductive. For ASPX or stock ASMX stuff, it was very easy. In fact, it's much easier than JWSDP, Axis or most other java WS toolkits. peter
  109. ASP.NET used to be on this list - but now JSF is available, with a nice model that is similar. ASP.NET still has many more controls than JSF, all shipped in the tool. In practice, then I think ASP.NET is still easier but will leave it off the list just in case.
    Interesting! Microsoft is here to promote JSF. Thank you, Microsoft.
  110. Expect a MS sponsored developer productivity comparison study between ASP.NET and JSF soon.
  111. Great idea![ Go to top ]

    Expect a MS sponsored developer productivity comparison study between ASP.NET and JSF soon.
    Hmmm, that is a great idea! If MS pays for it, that immediately invalidates the study, in some people's eyes. So in the interest of fairness and accuracy, you all will be wanting to pool funds to pay for the study, then?
  112. Re: Great idea![ Go to top ]

    Expect a MS sponsored developer productivity comparison study between ASP.NET and JSF soon.


    Hmmm, that is a great idea! If MS pays for it, that immediately invalidates the study, in some people's eyes. So in the interest of fairness and accuracy, you all will be wanting to pool funds to pay for the study, then?
    Just kidding. Havn't seen MS ever paid for a study to beat a loser.
  113. thanks for the list Dino. With your permission, I'd love to post this somewhere on the net, or maybe you have a link to this information on your own site/blog? -Trevor
  114. Delegates

    you gotta do a bunch of pushups in Java to accomplish the same thing. Way way back (1998), Sun thought the delegates in J++ were noteworthy enough to publish a paper on why real Java doesn't have delegates (http://java.sun.com/docs/white/delegates.html), going so far to say "It is unlikely that the Java programming language will ever include this construct." (Microsoft responded, http://msdn.microsoft.com/archive/en-us/dnarvj/html/msdn_deltruth.asp) I think BEA's Beehive thing had some nice eventing constructs. And if I am not mistaken, I think the "Java futures" talk at JavaOne 2006 mentioned something about a delegate-style construct, either in Java 6 or 7.
    Totally agree. Once used to C# delegate and event (as in WebForm or WinForm), its too hard to go back to the current Java way of doing events.
  115. I guess I cannot argue with your characterization of Microsoft's release of VB.NET and subsequent end-of-(mainstream)-support for VB6 as "leaving developers behind": there are lots of VB6 developers, and they need to learn new things to productively use VB.NET. But consider that situation relative to other tools vendors. Six years may not be enough for you - that's a fair statement to make - but six years is better than all the other mainstream developer tools I know of. If 6.5 years of support is "leaving developers behind" then how would you describe the situation with Sun Java Workshop 2.0 or IBM Visual Age for Java 1.0 or Symantec Visual Cafe?
    I guess Steve was referring mainly to languages changes, and not just tools. Of course tools come and go, they are products, and so it happens every day, no big deal. But languages per se are not products you sell as a box on a shelf (or at least should not be treated as such), so they should remain stable, and should evolve in a backward-compatible way whenever possible. Java has remained fairly stable since 1.0, although all the java tools you mentioned have come and gone in all these years. Not the same way with MS tools and languages, which sometimes are preatty tied to one another, so whenever a big language change comes, you have to shell out money for tool upgrades, and sometimes even OS upgrades in order to keep up with MS' innovations.
  116. I guess Steve was referring mainly to languages changes, and not just tools. Of course tools come and go, they are products, and so it happens every day, no big deal. But languages per se are not products you sell as a box on a shelf (or at least should not be treated as such), so they should remain stable, and should evolve in a backward-compatible way whenever possible.
    This is exactly what I was trying to say. It is acceptable for tools or IDEs to change, but Microsoft lost a lot of goodwill and trust because of the significant language changes from VB6 to VB.NET. I still have to deal with legacy VB6 code, and the migration path to Java is not that much more difficult than the migration to .NET, and I know which path I shall recommend...
  117. Re: couple of clarifications[ Go to top ]

    Cameron Purdy wrote:
    The real idiotic decision by Microsoft was to make it incompatible with Java, which means that developers are typically left with "either / or" choices. In the end, it will be the failure of .NET, because it's an all-or-nothing gambit (and I believe it provable that Microsoft cannot win "all").
    I'm not clear on what you mean by ".NET is an all-or-nothing gambit." Maybe this is obvious, but in case it isn't, there's nothing in the .NET license that says "by using .NET you promise to never develop another line of code in Java again."
    What I meant was this: Microsoft didn't "add to" a market, they went to create their own incompatible market. The result is competition (good), but the only reason that .NET hasn't already died is that Microsoft is covering the huge costs (what most companies would call "losses"). In other words, it's kind of like the XBox, which while it brings competition (good), it still loses over a billion a year for Microsoft, year after year after year. I'd personally hate to compete against a product that never has to make any money and that is subsidized by a massively profitable company with no chance of losing that profitability (due to a monopoly).
    An alternative view: If you look at the time and effort Microsoft has put into helping define XML and web services protocols - all dedicated to heterogeneous interoperability - and the time and effort Microsoft put into supporting those protocols in .NET, then you might logically conclude that Microsoft recognizes that heterogeneity is here to stay, and the MS development platform had better support it.
    Java was already entrenched, so they had to "cooperate". Microsoft's actions are always "cooperating" when they are losing and "exclusionary" when they think they have leverage to win. It was true in 1980. It was true in 1990. It was true in 2000. It is true today. Notice I'm not spelling their name with dollar signs or calling them evil .. I'm just pointing out an obvious tactic that is ingrained into the ethos of the company.
    Purdy:
    .NET (the Micosoft clean-room JVM) supports Java (albeit slightly broken and renamed as C#) and two slightly syntactically-disguised versions of Java called VB.NET and C++.NET.
    Purdy, you seemed like such a mild-mannered, level-headed software guy when you presented on distributed caching at JavaOne. When you talk about .NET it's as if reason flies out the window. ;) C# is a standard language. (see ECMA and ISO). It is similar to Java syntax, and you might even say it is derivative, but they are clearly two different languages. You can call it broken if you like, but a more accurate term might be "different." I won't argue opinions though. C++.NET is not a language. For a while Microsoft was attaching the ".NET" suffixe to everything, including C++. [..] Just for the record, .NET does support a Java syntax as well, via the J# language.
    First of all, I try to be witty, and the fact that I am not is no reflection on the effort that I put into it. I joked that C# was broken because of some of the silly choices made in it. My most hated one is the non-virtuality of methods. Welcome to cfront, circa late 1980s. BTW - I knew some of the people at Microsoft working on the clean room JVM before it was renamed to Cool before it was renamed to .NET. (Along this same line, another interesting thing that most people don't know is that Windows NT was originally the "OS/2 version 3" project at Microsoft. Ha-ha!) Anyhow, I still use J++ sometimes (it had a decent editor), and I've used C# extensively (research). I love the technology, and I think there are some real gems in .NET. I just wish that Microsoft were involved in the overall market, instead of taking their balls and going off to play with themselves. That little maneuver made .NET much less valuable to most of the known universe. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  118. Re: couple of clarifications[ Go to top ]

    What I meant was this: Microsoft didn't "add to" a market, they went to create their own incompatible market. The result is competition (good), but the only reason that .NET hasn't already died is that Microsoft is covering the huge costs (what most companies would call "losses").
    How is .NET supposed to die? You think people would be happy to go back to MFC/Win32 API? Java failed on the desktop. Java failed with applets. And now Java is failing with LAMP chewing it up on the low end. How much more failure can Java withstand?
  119. the trust is used up[ Go to top ]

    Why worry? If Microsoft is only 10% as lazy, evil and downright stupid as people say they can never compete anyhow! By the way, talking about the immediate future what do Java have in the way of Indigo/Avalon/IE7 with XAML? In my opinion the main reason NOT to work with Java is that you can not trust what people say about it. Both SUN and the whole Java community constantly over exaggerating (I do not say lying because I am polite). EJB 3.0 may or may not fix all the problems with J2EE. If you have been listening to all that said the last 5-6 years about the OLD EJB/J2EE and Big Java servers in general how can it be possible to trust these people again? Regards Rolf Tollerud
  120. Re: the trust is used up[ Go to top ]

    Why worry? If Microsoft is only 10% as lazy, evil and downright stupid as people say they can never compete anyhow!

    By the way, talking about the immediate future what do Java have in the way of Indigo/Avalon/IE7 with XAML?

    In my opinion the main reason NOT to work with Java is that you can not trust what people say about it. Both SUN and the whole Java community constantly over exaggerating (I do not say lying because I am polite). EJB 3.0 may or may not fix all the problems with J2EE. If you have been listening to all that said the last 5-6 years about the OLD EJB/J2EE and Big Java servers in general how can it be possible to trust these people again?

    Regards
    Rolf Tollerud
    +1 I agree. Once upon a time I championed the use of J2EE. After witnessing the birth of things like EJB CMR which quite frankly should have never seen the light of day, my confidence in Sun/JCP was shall I say challenged :^). Today I simply do not trust them, and each new standard (e.g EJB3.0) IMO confirms that they can't be trusted. Personally I'm putting my faith in open source. Paul.
  121. Re: the trust is used up[ Go to top ]

    I agree. Once upon a time I championed the use of J2EE. After witnessing the birth of things like EJB CMR which quite frankly should have never seen the light of day, my confidence in Sun/JCP was shall I say challenged :^).

    Today I simply do not trust them, and each new standard (e.g EJB3.0) IMO confirms that they can't be trusted. Personally I'm putting my faith in open source.

    Paul.
    Sorry Paul, but this doesn't make sense to me. There is absolutely no contradiction between using JCP standards and open source. None at all. Some of the most well known JSRs have open source implementations. Some of the most well-known JSRs have been strongly influenced by open source products (EJB 3.0/Hibernate). And, of course, having open source implementions of these specifications means that you don't have to trust anyone. Sorry, but I think you are setting up a false and confusing dichotomy between Sun/JCP on one side and 'open source' on the other. (A large number of open source projects are written using Java!)
  122. Re: the trust is used up[ Go to top ]

    Hi Steve,
    Sorry Paul, but this doesn't make sense to me. There is absolutely no contradiction between using JCP standards and open source.
    I didn't say there was.
    And, of course, having open source implementions of these specifications means that you don't have to trust anyone.
    My point entirely.
    Sorry, but I think you are setting up a false and confusing dichotomy between Sun/JCP on one side and 'open source' on the other. (A large number of open source projects are written using Java!).
    I'm not setting anything up. The side I'm on is "my side". Being on my side is leading me to make vendor independent technology choices (Spring, Hibernate, Tomcat, etc). I never said that Java was bad, or that all vendor products and Java standards are bad. What I said is that I no longer trust Sun/JCP to come up with standards that serve me. My experience is that heavily influenced vendor standards whether defacto in the case of Microsoft or committee based in the case of the Java Cartel, tend to serve themselves (the vendors). Hence my lack of trust. Paul.
  123. Re: the trust is used up[ Go to top ]

    Sorry Paul, but this doesn't make sense to me. There is absolutely no contradiction between using JCP standards and open source.
    I didn't say there was.
    I don't see how else one could interpret:
    my confidence in Sun/JCP was shall I say challenged :^). .... Today I simply do not trust them... Personally I'm putting my faith in open source.
    The fact that you wouldn't put your faith in someone you don't trust implies Sun/JCP != 'open source' :)
    Being on my side is leading me to make vendor independent technology choices (Spring, Hibernate, Tomcat, etc).

    I never said that Java was bad, or that all vendor products and Java standards are bad. What I said is that I no longer trust Sun/JCP to come up with standards that serve me.
    But this is a contradiction - as you have included Tomcat, which is the reference implementation of a JCP standard. This is why I don't thing the kind of sweeping statements you are making are useful for decision making.
    My experience is that heavily influenced vendor standards whether defacto in the case of Microsoft or committee based in the case of the Java Cartel, tend to serve themselves (the vendors). Hence my lack of trust.

    Paul.
    So don't use heavily influenced vendor standards! Not everything Sun and the JCP do are heavily influences by vendors. Use excellent standards like JDO, for example. Or perhaps, simply use vendor-influenced standards that happen to suit your purposes (like the stand-alone JSP/Servlet standard, as implemented by Tomcat - one of your technology choices above).
  124. Re: the trust is used up[ Go to top ]

    Hi Steve,
    Not everything Sun and the JCP do are heavily influences by vendors.
    Agreed.
    So don't use heavily influenced vendor standards!
    I don't.
    Not everything Sun and the JCP do are heavily influences by vendors.
    True.
    Use excellent standards like JDO, for example. Or perhaps, simply use vendor-influenced standards that happen to suit your purposes (like the stand-alone JSP/Servlet standard, as implemented by Tomcat - one of your technology choices above).
    I'm currently looking into JSF in detail as you suggested. It is a lot better then I first thought, and I believe I can use it in an Agile way. (I may could be using it on my next contract). Having said this IMO Webwork still seems simpler, and so far still remains my prefered web framework. I am still suspicious that the remit for the JSF team was to produce a web framework that created an opportunity for vendor tooling. I could be wrong. The question was about trust, and I simply do not trust the JCP to represent my best interests all the time. Paul.
  125. Re: the trust is used up[ Go to top ]

    I am still suspicious that the remit for the JSF team was to produce a web framework that created an opportunity for vendor tooling. I could be wrong.

    The question was about trust, and I simply do not trust the JCP to represent my best interests all the time.

    Paul.
    Personally, I don't care that much about the motivations of a JSR team. What matters to me is - can I use products based on the JSR in a way that suits me? The tooling support of JSF is surely irrelevant if it allows easy use without tools (and it does). But anyway, there is nothing fundamentally wrong about support for vendor tooling. One of the finest Java development products - Spring - was, in a way, designed to allow for vendor tooling through its use of XML - a very tool-friendly format. What I am cautious of using is specifications which seem (at least to me) to be encourage (by design or otherwise) vendor-specific extensions (this is a reason why I dislike parts of EJB 3.0, and this was also a fault of JDO 1.0). But, I see the issue of a JSR encouraging vendor extensions being quite different from the issue of encouraging the development of vendor tools. The first is not developer-friendly, the second can certainly be.
  126. Re: the trust is used up[ Go to top ]

    I am still suspicious that the remit for the JSF team was to produce a web framework that created an opportunity for vendor tooling. I could be wrong.

    The question was about trust, and I simply do not trust the JCP to represent my best interests all the time.

    Paul.


    Personally, I don't care that much about the motivations of a JSR team. What matters to me is - can I use products based on the JSR in a way that suits me? The tooling support of JSF is surely irrelevant if it allows easy use without tools (and it does). But anyway, there is nothing fundamentally wrong about support for vendor tooling. One of the finest Java development products - Spring - was, in a way, designed to allow for vendor tooling through its use of XML - a very tool-friendly format.

    What I am cautious of using is specifications which seem (at least to me) to be encourage (by design or otherwise) vendor-specific extensions (this is a reason why I dislike parts of EJB 3.0, and this was also a fault of JDO 1.0).

    But, I see the issue of a JSR encouraging vendor extensions being quite different from the issue of encouraging the development of vendor tools. The first is not developer-friendly, the second can certainly be.
    I could take you through a number of JSR's point by point, and my problem with them, but that wouldn't help. I'm just saying that the overall feeling I get is that the motives of the JCP aren't soley to make my life easier, and at times my interests and vendor interests do come into conflict. At these moments I do not trust the JCP to best represent me. Paul.
  127. Re: the trust is used up[ Go to top ]

    I could take you through a number of JSR's point by point, and my problem with them, but that wouldn't help. I'm just saying that the overall feeling I get is that the motives of the JCP aren't soley to make my life easier, and at times my interests and vendor interests do come into conflict.

    At these moments I do not trust the JCP to best represent me.

    Paul.
    Are the motives of any software project solely to make your life easier, and won't you come into conflict with other interests occasionally no matter what product you use? I have certainly come across with such conflicts with open source products. I would rather have some process that at least attempted to get vendors and developers together to produce things according to some common specification than to allow an endless series of incompatible implementations of poorly-specified standards. I have been through that sort of mess before with languages other than Java, and it was not pretty.
  128. Re: the trust is used up[ Go to top ]

    Hi Steve, Yes I agree the JCP is better than nothing. But you have failed to address the central issue of trust. The original post on the subject of trust implied that Sun had used up the Trust of the developer commnity. I agree. So the issue is what we as developers can do to rectify the situation and how can that trust be re-established. Personally I feel that the root of the problem lies in the original business model Sun set up when they introduced Java as an enterprise platform. Please see my earlier post:
    I think this shows the need for strong jee standards. Companies shouldn't have to consider all the alternative frameworks when choosing jee, the j2ee standard should be competative to .net by in itself. It should be complete without the need for extra frameworks. Open source projects should be a sandbox/laboratry where cool new things are tried. These things should be incorporated into the standards when proven useful.
    +1 I totally agree. Not sure how it would work in practice though. The J2EE community includes commercial vendors. I'm not sure how they could compete with JCP ratified open source standards whose implementations found their way out of the sandbox into full blown production use. I guess they could use the JBoss model and offer support and consulting services, or they could get into adding additional "non-standard" features. My feeling is that from the beginning J2EE has been dominated by vendor interests and has had the dilemma of allowing commercial competition, whilst maintaining universal standards. Many of the most promising new ideas (e.g. light weight containers, JVM scripting languages etc) will mean vendors ditching their incumbent installed customer base. If they can't offer new features as complimentary to their existing product to existing customers then they will end up having to compete head on with open source implementations of JCP ratified standards. This is the reason IMO why EJB3 has been shackled with all the baggage of EJB2.1 which the vendors have implemented and where they have a large installed base. The advantage Microsoft has got is that they can ditch their past and re-invent themselves when ever they like since they seem to have a near development tool monopoly on the windows platform. This dilemma in J2EE has been there from the inception IMO. Languages like C, C++ came from the research community and the standard language was never really "owned" by vendors. Languages like Squeak and Ruby belong to their development community so are free from vendor interests too. Java and J2EE seem dominated by big vendors like Sun, BEA, IBM, Oracle etc. I just can't see these vendors giving up this position of dominance lightly, after all their primary responsibility is to their shareholders not to the Java development community. I guess they could be made to truly compete amongst themselves rather than agreeing on cosy "design-by comittee" standards up front. Us the developer community could then deciding which commercial/open source solution (or combination of solutions) to ratify as the JCP standard once they all had been tested in the market. If this was the case, then the vendors would be forced to put their research budgets to some good use and actually innovate.
    I think there is a worth while debate to be had on how best to move forward, and it may just require reforming the JCP. What ever happens, I believe that we as the developer community need to take more responsiblity for our own futures and be in the driving seat. If we do not take on this responsiblity and leave it to vendors, my concern is that eventually our customers could end up loosing trust in us! How many failed IT projects will the business community tolerate? Paul.
  129. Re: the trust is used up[ Go to top ]

    The original post on the subject of trust implied that Sun had used up the Trust of the developer commnity. I agree. So the issue is what we as developers can do to rectify the situation and how can that trust be re-established.
    I think this is plain nonsense. Sun is, and remains, one of the most trusted companies in terms of development languages, platforms and tools. The original post was from someone who has been doing little but posting evidence-free pro-Microsoft and anti-Java rants on this forum for years. You really don't help your argument by referring to his posts. Java is a hugely popular language and use of JCP specifications is widespread (just think of the number of applications that use the JSP/Servlet API!). Individual dislike of certain JSRs does not detract from that, or does not indicate that Sun has 'used up the Trust of the developer community' in any way.
    Personally I feel that the root of the problem lies in the original business model Sun set up when they introduced Java as an enterprise platform.

    Please see my earlier post:
    I think this shows the need for strong jee standards. Companies shouldn't have to consider all the alternative frameworks when choosing jee, the j2ee standard should be competative to .net by in itself. It should be complete without the need for extra frameworks.
    J2EE is very competitive with .NET already, and there are, of course, already strong JEE standards. Microsoft would do anything to get the server-side presence that J2EE has. Sure, it would be great if JEE was more agile (and EJB 3.0/JPA, for all its faults, is a step towards that). I see the ability to combine different frameworks and approaches with a core JEE approach as a huge strength, not a weakness.
    If we do not take on this responsiblity and leave it to vendors, my concern is that eventually our customers could end up loosing trust in us!

    How many failed IT projects will the business community tolerate?

    Paul.
    I think you are falsely putting a huge amount of blame for failed projects on J2EE (or rather, bits of it you don't like, such as EJBs). Anyone with long-term experience of IT realises that projects have been failing for a very, very long time, no matter what the language or development practices. You are basically re-iterating an argument I heard even back in the 70s. Things are progressing. There are great frameworks like JSF which form part of JEE. EJB has become far more agile with EJB 3.0. Java 6 will have support for scripting languages. There are JSRs for dynamic languages.
  130. Re: the trust is used up[ Go to top ]

    Hi Steve, I guess it is a cup half full versus a cup half empty scenario. My view is that as far as software development is concerned, my cup is always half empty. If I was a business, I wouldn't have much faith in the IT industry delivering. Personally, I do not think as a whole we offer good value for money. I'm not picking on JEE specifically, but generally as a profession IMO we put on a pretty poor showing. My experience as a contractor has shown that by and large the business community has lost a lot of trust in the IT industry already (think Y2K). Business Managers tend to use IT projects as political footballs with very little faith that they will actually deliver business value (infact on my current project, the business was wrong footed when we did actually deliver). The reasons for this IMO are complex, but IMO vendor dominance doesn't help. Paul.
  131. Re: the trust is used up[ Go to top ]

    but generally as a profession IMO we put on a pretty poor showing.
    I agree with you.
    My experience as a contractor has shown that by and large the business community has lost a lot of trust in the IT industry already (think Y2K). Business Managers tend to use IT projects as political footballs with very little faith that they will actually deliver business value (infact on my current project, the business was wrong footed when we did actually deliver).

    The reasons for this IMO are complex, but IMO vendor dominance doesn't help.

    Paul.
    I am lucky to have worked in a different environment, where small projects can deliver a significant value to the user - and this is very rewarding. It is not all bad out there, even though what you say has a lot of truth in it!
  132. I have read most of the comments in this thread and felt compelled to comment.
    The original post on the subject of trust implied that Sun had used up the Trust of the developer commnity. I agree. So the issue is what we, as developers, can do to rectify the situation and how can that trust be re-established.


    I think this is plain nonsense. Sun is, and remains, one of the most trusted companies in terms of development languages, platforms and tools.
    This proposition is simply false. The rapidly growing popularity of Hibernate, Spring, Tapestry, Echo, Wicket and other OSS frameworks and tools (e.g., Ant, JUnit) are ample evidence that J2EE developers do not trust Sun, especially in light of its disatrous record with EJB and other J2EE technologies. OSS frameworks and tools are popular, in part, because J2EE developers no longer trust Sun. Furthermore, EJB 3.0 simply incorporates (or steals, depending on your point of view) design patterns in Hibernate and Spring. If Sun had been competent, EJB 1.0 would have resembled Hibernate and Spring.
    Another indicator of the lack of trust in Sun (among developers) is the growing movement towards alternative frameworks and platforms, including RoR and Zope-Plone. In the next several years, this movement (towards alternatives) could well become a stampede. Currently, I see many, many smart developers investigating RoR and Zope-Plone.
  133. Sun is, and remains, one of the most trusted companies in terms of development languages, platforms and tools.
    This proposition is simply false. The rapidly growing popularity of Hibernate, Spring, Tapestry, Echo, Wicket and other OSS frameworks and tools (e.g., Ant, JUnit) are ample evidence that J2EE developers do not trust Sun, especially in light of its disatrous record with EJB and other J2EE technologies. OSS frameworks and tools are popular, in part, because J2EE developers no longer trust Sun. Furthermore, EJB 3.0 simply incorporates (or steals, depending on your point of view) design patterns in Hibernate and Spring. If Sun had been competent, EJB 1.0 would have resembled Hibernate and Spring.
    Yes, while Gavin slept, someone stole his ideas and put them into EJB3. Or perhaps, Sun built a community that worked together, and Gavin was actually instrumental in building EJB3? Who trusts whom now? ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  134. Who trusts whom now? ;-)
    Sun trusts Microsoft to figure out what features should be in the next version of Java ;)
  135. I have read most of the comments in this thread and felt compelled to comment.

    The original post on the subject of trust implied that Sun had used up the Trust of the developer commnity. I agree. So the issue is what we, as developers, can do to rectify the situation and how can that trust be re-established.


    I think this is plain nonsense. Sun is, and remains, one of the most trusted companies in terms of development languages, platforms and tools.

    This proposition is simply false. The rapidly growing popularity of Hibernate, Spring, Tapestry, Echo, Wicket and other OSS frameworks and tools (e.g., Ant, JUnit) are ample evidence that J2EE developers do not trust Sun, especially in light of its disatrous record with EJB and other J2EE technologies.
    There is a major contradiction here. What are these frameworks based on? All are based on Java, and most are based on J2EE. Not exactly a sign of a lack of trust. They are indications of innovations around what Sun provides. Also, to claim that EJB and other aspects of J2EE have a 'disastrous record' is, to put it bluntly, total nonsense. Some of J2EE could have been better (such as EJB CMP), but it has still been successful by any standards, and widely used (no matter how painful to develop with!).
    OSS frameworks and tools are popular, in part, because J2EE developers no longer trust Sun.
    No, because they want to do things differently or do things that Sun does not provide. I would suggest that this is little to do with trust. (Also, I find statements like 'J2EE developers no longer trust Sun' to be so broad as to be meaningless - if there has been some survey to demonstrate this, I would be interested, but otherwise, I can't take it seriously).
    Furthermore, EJB 3.0 simply incorporates (or steals, depending on your point of view) design patterns in Hibernate and Spring. If Sun had been competent, EJB 1.0 would have resembled Hibernate and Spring.
    You can't sum up everything to do with Java and Sun products in terms of EJB. This is a very narrow point of view. Sure, Sun made some mistakes, both in implementation and marketing of this technology, but there have also been a large number of very successful uses of it.
    Another indicator of the lack of trust in Sun (among developers) is the growing movement towards alternative frameworks and platforms, including RoR and Zope-Plone. In the next several years, this movement (towards alternatives) could well become a stampede. Currently, I see many, many smart developers investigating RoR and Zope-Plone.
    I have heard such comments about various technologies for years. You get a lot of this kind of thing on forums like Slashdot... 'Sun is dying', 'PHP is killing Java' and now 'RoR will become the major way to develop websites'. Meanwhile, use of Java continues to grow, taking over from well-established languages even in open source communities like Sourceforge. I think you are over-reacting to a statement which I should perhaps have qualified. Sun is one of the most trusted companies in terms of development languages, tools and products - at least among those who are prepared to trust companies with these things. There is a significant developer community that finds less tightly controlled languages like PHP and Ruby more appealing (I do for some uses).
  136. Of course Cameron will deny that there are any trust issue, he who has defended all versions of EJB so far with equal vehemence. IMO the extremely peculiar happening of hundreds of thousands experienced consultants jumping uncritical aboard the J2ee/Ejb bandwagon constitute one of the great miracles in the world of human history - full on par with the tulip craze in Amsterdam in the 17 century. Right now Java and .Net is about neck and neck, To think that Java can stand up against a very determined (good old capitalist) Microsoft who is understandably angry over how they was tricked by the whole Java business is beyond my comprehension. Regards Rolf Tollerud
  137. Right now Java and .Net is about neck and neck,
    Are they really? I thought that according to your detailed analysis of job statistics in posts some time ago that Java should have been long dead by now?
  138. Java vs .Net[ Go to top ]

    "Are they really? I thought that according to your detailed analysis of job statistics in posts some time ago that Java should have been long dead by now?" I though the article at http://www.businessweek.com/technology/content/dec2005/tc20051213_042973.htm summed it up nicely? That was last round. Next round starting with Vista in january. (give or take a few weeks) Best regards Rolf Tollerud
  139. No new tricks[ Go to top ]

    "Are they really? I thought that according to your detailed analysis of job statistics in posts some time ago that Java should have been long dead by now?" I though the article at http://www.businessweek.com/technology/content/dec2005/tc20051213_042973.htm summed it up nicely? That was last round. Next round starting with Vista in january. (give or take a few weeks) Best regards Rolf Tollerud
    The reality is neither Java nor .NET will go away within the next 5 years. It's just not going to happen. It's better to understand where each technology fits and "try" to use each one correctly. Forgetting for the moment that management can and do make decisions based on sales pitch. In 10-15 years, most everyone year will probably learn something else, since a new thing will try to replace both java and .NET. peter
  140. Re: Java vs .Net[ Go to top ]

    "Are they really? I thought that according to your detailed analysis of job statistics in posts some time ago that Java should have been long dead by now?"

    I though the article at http://www.businessweek.com/technology/content/dec2005/tc20051213_042973.htm

    summed it up nicely?
    Not really. No matter how many articles you quote, this does not help to make your past predictions of the demise of Java any less innacurate or (especially in hindsight) amusing :)
  141. "Not really. No matter how many articles you quote, this does not help to make your past predictions of the demise of Java any less inaccurate or (especially in hindsight) amusing :)" What bother me is the audacity to continue as if the J2EE/Ejb thing never happened. It is similar to western leftist intellectuals that raised Soviet and the communist system to the sky and travelled to Cambodia and wrote home reports of how idyllic and praiseworthy everything was. If I was one of them I would try hide behind a stone or something! But no, they continue to write newspaper articles and generally behave as nothing has happened. "Pretending it is raining" I believe it is called in british terminology. Regards Rolf Tollerud
  142. What bother me is the audacity to continue as if the J2EE/Ejb thing never happened
    Ah yes. That J2EE/EJB thing that was so successful that it led to sites like EBay; the subject of current interest by Microsoft: http://www.heise.de/english/newsticker/news/73609 Even Microsoft realise the success of sites which run on Sun hardware and are powered by J2EE. When are you going to catch up with Microsoft?
  143. ejb or not ejb you still pay[ Go to top ]

    Invest enough time and money and you can get everything to work. With J2EE/EJB and IBM as consultants :) the cost is normally about 10-20 times more than it should be. But in the special case of eBay though the bill is probably 100 times more. If Microsoft really is interested in buying eBay it is probably because they are keen to show how much cheaper , faster and better it will be to implement it in .NET. Regards Rolf Tollerud
  144. Re: ejb or not ejb you still pay[ Go to top ]

    Invest enough time and money and you can get everything to work. With J2EE/EJB and IBM as consultants :) the cost is normally about 10-20 times more than it should be. But in the special case of eBay though the bill is probably 100 times more. If Microsoft really is interested in buying eBay it is probably because they are keen to show how much cheaper , faster and better it will be to implement it in .NET. Regards Rolf Tollerud
    ok, I'm gonna have to call you on this one. Do you know how ebay's system works and what they actually use? Do you know what kind of hardware, software and architecture? What database do they use and how are transactions routed? What kind of rule engine does ebay use to filter transactions and items posted for sale? I can tell you right now, ebay uses iLog JRules rule engine in sequential evaluation mode. The other parts I don't know, but iLog is working on getting their .NET version to the same level as their java rule engine. How would Microsoft make the website run faster in .NET without a high performance rule engine? The last I heard, ebay was moving to Tomcat, but that's just rumors. peter
  145. the "secret" weapon[ Go to top ]

    What I know about eBay is from the Sun case study at http://www.sun.com/service/about/success/ebay.xml "How would Microsoft make the website run faster in .NET without a high performance rule engine?" You really think that Microsoft could not do eBay if they wanted to? That what people said when they bought Hotmail too. About "high performance rule engine" so will I remind you of one of Microsoft's "not-so-secret-practices": Handwritten assemble code by real experts in critical places. "The last I heard, ebay was moving to Tomcat, but that's just rumors" Ha ha, that would be the wise thing to do. Regards Rolf Tollerud
  146. Re: the "secret" weapon[ Go to top ]

    About "high performance rule engine" so will I remind you of one of Microsoft's "not-so-secret-practices": Handwritten assemble code by real experts in critical places.
    As you pointed out: "Invest enough time and money and you can get everything to work." I thought you meant that as a negative thing. Except, I guess, when it applies to MS technology.
  147. Re: the "secret" weapon[ Go to top ]

    That what people said when they bought Hotmail too.
    And they were right .. the cost of developing and running Hotmail went through the roof .. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  148. Re: the "secret" weapon[ Go to top ]

    What I know about eBay is from the Sun case study at
    http://www.sun.com/service/about/success/ebay.xml

    "How would Microsoft make the website run faster in .NET without a high performance rule engine?" You really think that Microsoft could not do eBay if they wanted to? That what people said when they bought Hotmail too. About "high performance rule engine" so will I remind you of one of Microsoft's "not-so-secret-practices": Handwritten assemble code by real experts in critical places. "The last I heard, ebay was moving to Tomcat, but that's just rumors" Ha ha, that would be the wise thing to do. Regards
    Rolf Tollerud
    So you're saying business analysts are going to write assembly for the business rules? Or that a business guy is going to give rules to an hardcore assembly programmer to crank out super optimized code? What happens if they need to change rules every hour to filter out inappropriate items? How fast can this hypothetical "assembly guru" convert rules to executable code and how will it be deployed on the fly to a cluster of production systems? To the best of my knowledge of rule engine theory, technology and history, that's impractical. Of course I'm bias, since I work on RETE rule engines. For the record, it is feasible to write a high performance rule engine in .NET using C#. I've ported a rule engine from Java to .NET in the past, so I have some experience with it. There are some differences like threading, which require different techniques for scaling out rule engines, but it is possible. peter
  149. About "high performance rule engine" so will I remind you of one of Microsoft's "not-so-secret-practices": Handwritten assemble code by real experts in critical places.
    Rolf Tollerud
    Oh man, this has *got* to be one of the top-ten IT quotes of all time!!! LOL!!
  150. Re: the "secret" weapon[ Go to top ]

    About "high performance rule engine" so will I remind you of one of Microsoft's "not-so-secret-practices": Handwritten assemble code by real experts in critical places.
    Rolf Tollerud

    Oh man, this has *got* to be one of the top-ten IT quotes of all time!!! LOL!!
    This site, and Rolf, is still really amusing. Replacing rules engines with handcoded assembler, and ajax as a competitor to j2ee and .net, in the same thread...
  151. Re: couple of clarifications[ Go to top ]

    >How is .NET supposed to die? You think people would be happy to go back to MFC/Win32 API?
    Microsoft development tools and products don't usually die through developers having to move backwards. They die because Microsoft comes up with some other newer approach and drops support for previous ones. This has even happened with one of the most successful development tools/languages of all time - Visual Basic. There is no reason why .NET as it currently is designed should not suffer the same fate - '.NET 4.0' (or whatever it is called) may be quite a different framework.
  152. Like .NET 2.0[ Go to top ]

    >How is .NET supposed to die? You think people would be happy to go back to MFC/Win32 API?
    Microsoft development tools and products don't usually die through developers having to move backwards. They die because Microsoft comes up with some other newer approach and drops support for previous ones. This has even happened with one of the most successful development tools/languages of all time - Visual Basic. There is no reason why .NET as it currently is designed should not suffer the same fate - '.NET 4.0' (or whatever it is called) may be quite a different framework.
    In .NET 2.0, there's already a lot of breaking changes, which are documented. But I'd argue companies using Microsoft products already expect breaking changes from one release to the next. I'm ok with some breaking changes, as long as it's well documented and people understand the cost in the long run. All vendors are guilty of this, but ROI studies tend to ignore this factor when cost is calculated. peter
  153. Re: couple of clarifications[ Go to top ]

    They die because Microsoft comes up with some other newer approach and drops support for previous ones.
    This has even happened with one of the most successful development tools/languages of all time - Visual Basic. There is no reason why .NET as it currently is designed should not suffer the same fate - '.NET 4.0' (or whatever it is called) may be quite a different framework.
    OMG, you mean things change? Say it isn't so. Does Microsoft come and confiscate those unsupported tools too, so you have to upgrade? I heard Ballmer and Gates are making the rounds deleting all those copies of VB6 and passing out shiny new VS2005 boxes.
  154. Re: couple of clarifications[ Go to top ]



    OMG, you mean things change? Say it isn't so. Does Microsoft come and confiscate those unsupported tools too, so you have to upgrade? I heard Ballmer and Gates are making the rounds deleting all those copies of VB6 and passing out shiny new VS2005 boxes.
    I work on projects which are expected to have a long lifetime. They will need support for the language used for that development during this long lifetime, and at least the possibility of a clear migration path to future versions of the language. Many developers and projects don't have this requirement; they can use the latest fashionable language, toolkits or development processes. My situation is different, and I am not alone. The announcement of the significant incompatibilities between VB6 and VB.NET meant to me that Ballmer and Gates had effectively deleted VB6 as a possible development language for my use. Fortunately I was not personally using VB6 at the time (although I have had to support projects using it). I was not using it because I had experienced such problems with Microsoft development products before. I realise these aren't problems for everyone - Microsoft's approach to this gives them a lot of freedom to introduce new products and change them to suit at least some parts of the developer market - but they are a problem for me.
  155. Re: couple of clarifications[ Go to top ]

    I work on projects which are expected to have a long lifetime.
    You do realize that VB6 apps will be running on 98, XP, Server, Vista for some time to come, right?...And that the VB6 IDE will be around for as long as you want it?...and the platforms that will run VB6 will be around for.......ever basically.
    They will need support for the language used for that development during this long lifetime, and at least the possibility of a clear migration path to future versions of the language.
    Yeah, and there will probably come a day where you will be rewriting some Java code to get up to speed on software advancements in the second and third decade of the 21st century. By the way, I believe Microsoft did offer some tool to help in migrating VB6 to VB.NET.
    My situation is different, and I am not alone.
    And nobody is going to take away the platforms, tools, and hardware to maintain that software.
    The announcement of the significant incompatibilities between VB6 and VB.NET meant to me that Ballmer and Gates had effectively deleted VB6 as a possible development language for my use
    No, it was only deleted if you want it to be deleted.
    I realise these aren't problems for everyone - Microsoft's approach to this gives them a lot of freedom to introduce new products and change them to suit at least some parts of the developer market - but they are a problem for me.
    Once again, nothing ever goes away. Ballmer and Gates won't come to your company and confiscate your machines, your legacy development tools, and the operating systems that run on them. Your VB6 projects can have as long of a lifetime as your company wants them to have.
  156. Re: couple of clarifications[ Go to top ]

    The announcement of the significant incompatibilities between VB6 and VB.NET meant to me that Ballmer and Gates had effectively deleted VB6 as a possible development language for my use
    No, it was only deleted if you want it to be deleted.
    No, it was effectively removed as a choice. If the vendor no longer is actively supporting it, it cannot be used by many organizations. When the annoucement came about VB6 EOL, there was a mass migration (some to VB.NET, but many to C# and Java) because a lot of companies have policies that say they cannot develop on (or even run on for more than a period of time) software that has been EOL'd. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  157. Re: couple of clarifications[ Go to top ]

    No, it was effectively removed as a choice. If the vendor no longer is actively supporting it, it cannot be used by many organizations. When the annoucement came about VB6 EOL, there was a mass migration (some to VB.NET, but many to C# and Java) because a lot of companies have policies that say they cannot develop on (or even run on for more than a period of time) software that has been EOL'd.
    And I'm sure many companies continued to write GW-Basic after it had been EOL'd, and the same with VB. But of course your straw grasping is irrelevant to your posts about failure and dying of .NET. And yes, Java will be effectively removed as choice one of these days too.
  158. No, it was effectively removed as a choice. If the vendor no longer is actively supporting it, it cannot be used by many organizations. When the annoucement came about VB6 EOL, there was a mass migration (some to VB.NET, but many to C# and Java) because a lot of companies have policies that say they cannot develop on (or even run on for more than a period of time) software that has been EOL'd.
    And I'm sure many companies continued to write GW-Basic after it had been EOL'd, and the same with VB. But of course your straw grasping is irrelevant to your posts about failure and dying of .NET. And yes, Java will be effectively removed as choice one of these days too.
    Just because some companies continue to use a tool (like VB) that has bee EOL'd, doesn't it is ok for other companies. I know of plenty of companies that have that kind of policy. Obviously, some companies are fine with tools and langauges that do not have commercial support, but are these the same kind of companies Steve and Cameron are talking about? My guess is no. You're talking about one kind of company that is comfortable with one set of tools, while large financial corps are quite different. my bias 2 cents peter
  159. Re: couple of clarifications[ Go to top ]

    Yeah, and there will probably come a day where you will be rewriting some Java code to get up to speed on software advancements in the second and third decade of the 21st century.
    Yes, but the issue is how far away that day is. It is unquestionably further away with a language that may implementations from many companies and is very widely used internally for major projects within major companies like IBM, Sun, Oracle etc. The companies who produce Java also use Java and will have a strong motivation to assist with any future migration.
  160. Re: couple of clarifications[ Go to top ]

    Yes, but the issue is how far away that day is. It is unquestionably further away with a language that may implementations from many companies and is very widely used internally for major projects within major companies like IBM, Sun, Oracle etc. The companies who produce Java also use Java and will have a strong motivation to assist with any future migration
    And you don't think that Microsoft has a motivation to assist with future migration to VB.NET? http://www.microsoft.com/downloads/details.aspx?FamilyId=10C491A2-FC67-4509-BC10-60C5C039A272&displaylang=en How much assistance was IBM giving to people migrating from COBOL to Java? I await the but..but.
  161. Re: couple of clarifications[ Go to top ]

    And you don't think that Microsoft has a motivation to assist with future migration to VB.NET?http://www.microsoft.com/downloads/details.aspx?FamilyId=10C491A2-FC67-4509-BC10-60C5C039A272&displaylang=en
    How much assistance was IBM giving to people migrating from COBOL to Java?

    I await the but..but.
    But... but... Firstly, a tool that "measures upgrade effort" is not something I would consider as a particularly useful tool to actually assist with the migration itself. Secondly, I base my opinion not on possible future motivations that Microsoft might have, but on long experience of how they have behaved in the past. I guess I don't have your optimism and faith in them. Regarding COBOL - what migration? IBM still support it. You don't have to migrate off of COBOL - it has not reached its end-of-life. I expect similar long-term support for Java which is the point I have been trying to make.
  162. Re: couple of clarifications[ Go to top ]

    Firstly, a tool that "measures upgrade effort" is not something I would consider as a particularly useful tool to actually assist with the migration itself.
    And you thought there weren't tools to assist in the migration? http://www.artinsoft.com/pr_vbcompanion.aspx
    Secondly, I base my opinion not on possible future motivations that Microsoft might have, but on long experience of how they have behaved in the past. I guess I don't have your optimism and faith in them.
    I dont' have faith and optimism in Sun, IBM, Microsoft, Borland...because I don't need faith and optimism in them.
    Regarding COBOL - what migration? IBM still support it. You don't have to migrate off of COBOL - it has not reached its end-of-life. I expect similar long-term support for Java which is the point I have been trying to make.
    You inaverdantly made my point. You don't have to migrate off of VB or GW-Basic or PL-1 if you don't want to. And who exactly do you want to hold your hand for your "support"? I'm sure there's plenty of "support" in VB land. VB has been one of the most (if not the most) popular language in history. I'm sure there's plenty of people out there that can "support" you. By the way, VB support from Microsoft doesn't end until January, '08. http://www.ftponline.com/vsm/2002_08/magazine/departments/ednote/ But of course this has nothing to do with VB6, as you and I know. Cameron stuck his foot in his mouth, once again, and I guess you felt the need to quickly change the subject on his behalf.
  163. Re: couple of clarifications[ Go to top ]

    I worked in a Microsoft centric shop a few years back and even they had a no VB policy. If anything new was going to be written, it had to VB.NET. A couple of people tried using VB, but got a major slap on the hand. Sure the official date for end of support is in the future, but even in 2003 companies were told plain VB would go away. Based on Microsoft's recommendation, this particular company decided no VB was the way to go. They even had plans to migrate all VB stuff to C#, so I fail to see how moving off VB is purely optional. If a small shops finds it acceptable, then sure they can keep using it. Many companies have policies that state otherwise. As a developer, it doesn't matter if everyone loves VB. If the management decides VB is not allowed because in 2008 support is ending, you have no choice. I don't have any numbers or statistics on VB support, but how many companies buy VB support from a third party? How many rely on microsoft pure for VB support? In other words, if there is a bug in VB, who do they go to? Do they go to a third party to fix the bug in VB, or do they go to microsoft? Are there third parties with access to Microsoft's VB source code? Is it possible to provide third party VB support without access to the source? I don't know these answers, so I'm hoping you can shed some light. peter
  164. Re: couple of clarifications[ Go to top ]

    And you thought there weren't tools to assist in the migration?
    Where did I say that? Of course there are tools to help. The fact that you need such tools indicates that it is not trivial.
    Regarding COBOL - what migration? IBM still support it. You don't have to migrate off of COBOL - it has not reached its end-of-life. I expect similar long-term support for Java which is the point I have been trying to make.


    You inaverdantly made my point. You don't have to migrate off of VB or GW-Basic or PL-1 if you don't want to.
    You are completely missing the point. Let me say it again. You don't have to migrate off of COBOL because it has not reached its end-of-life. There is an on-going strategy of support. Partly because it is still quite widely used, and partly because it is a multi-vendor language. This is very likely to be the future situation for Java. Microsoft has stated that there will not be continuing support for pre-.NET Visual Basic. Effectively they have changed the language and told developers they had better migrate if they want continued support. Migration is not trivial. I really don't see how this can be put any clearer. Some of us have explained why we don't want to, or are not allowed to, use unsupported languages, and the continued physical present of the development tool's CD in our offices is of no relevance.
    And who exactly do you want to hold your hand for your "support"? I'm sure there's plenty of "support" in VB land. VB has been one of the most (if not the most) popular language in history. I'm sure there's plenty of people out there that can "support" you.
    No, they can't. They can't easily supply bug fixes or patches as VB is not multi-vendor.
    By the way, VB support from Microsoft doesn't end until January, '08.
    So developers only have just over 18 months left. At that point Microsoft will be able to release service patches for future versions of Windows that potentially break VB6 programs. (I am not saying that they will, just that there will be nothing to stop them). That article may say that 6 years is "near-eternity in computer time", but many of us expect our software to be used and maintained for far longer than that. Seems like Microsoft has a different perspective on these things - which is why I'm so cautious about using their stuff.
  165. Re: couple of clarifications[ Go to top ]

    By the way, VB support from Microsoft doesn't end until January, '08.
    So developers only have just over 18 months left.
    Unless something changed, VB6 was EOL'd over a year ago. No more patches, even for "criticals". It's been years since any VB6 service packs were made available. My VB6 apps don't run on .NET. My JDK 1.0.2 code from 1996 runs fine on JDK 1.5, ten years later, with no EOL in sight. That's why enterprise software is built in Java. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  166. Re: couple of clarifications[ Go to top ]

    nless something changed, VB6 was EOL'd over a year ago. No more patches, even for "criticals".

    It's been years since any VB6 service packs were made available.
    Seems you are right. The latest service pack for VB6 was released 29th March 2004. If I were a VB6 developer, I would be confused.
  167. Re: couple of clarifications[ Go to top ]

    Unless something changed, VB6 was EOL'd over a year ago. No more patches, even for "criticals".
    The article said '08.
    My VB6 apps don't run on .NET.
    My Pascal code doesn't run on .NET either.
    That's why enterprise software is built in Java.
    And C++, and C#, and COBOL, and C, and... Nice try Cameron.
  168. Re: couple of clarifications[ Go to top ]

    My Pascal code doesn't run on .NET either
    Of course it does. http://www.borland.com/uk/products/delphi/index.html Delphi for .NET
  169. Re: couple of clarifications[ Go to top ]

    Of course it does. http://www.borland.com/uk/products/delphi/index.html Delphi for .NET
    Forgot about Delphi.NET, but Delphi isn't Pascal, just VB6 isn't VB.NET
  170. Re: couple of clarifications[ Go to top ]

    Unless something changed, VB6 was EOL'd over a year ago. No more patches, even for "criticals".
    The article said '08.
    Microsoft said last year. (BTW - That article is from the stone age.)
    My VB6 apps don't run on .NET.
    My Pascal code doesn't run on .NET either.
    So you are saying that VB.NET is not VB. My bad. VB.NET is a completely new thing with backwards compatibility for nothing, despite the naming implications ..
    That's why enterprise software is built in Java.
    And C++, and C#, and COBOL, and C, and... Nice try Cameron.
    There's legacy enterprise softare already built in C/C++, and of course in COBOL. I see almost no new enterprise software being built today in those languages. As for C#, I already explained why most enterprise software isn't built using a proprietary language environment that can be arbitrarily EOL'd at any point in time. I like C# (minus a few details), and would love to see Microsoft and Sun and IBM (etc.) working together to build out an open software infrastructure platform for the next 30 or 100 years that will support Java, C#, etc. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  171. Re: couple of clarifications[ Go to top ]

    So you are saying that VB.NET is not VB. My bad. VB.NET is a completely new thing with backwards compatibility for nothing, despite the naming implications ..
    Apparently, you are the only one confused about VB.NET not being VB.
    There's legacy enterprise softare already built in C/C++, and of course in COBOL. I see almost no new enterprise software being built today in those languages.
    What enterprise(y) software do you see being built? I think there's still plenty of enterprisey software being written in C++.
    As for C#, I already explained why most enterprise software isn't built using a proprietary language environment that can be arbitrarily EOL'd at any point in time.
    I guess you haven't heard of the ECMA specs or Mono.
    I like C# (minus a few details), and would love to see Microsoft and Sun and IBM (etc.) working together to build out an open software infrastructure platform for the next 30 or 100 years that will support Java, C#, etc.
    You've already got it. It's called the CLR and IKVM. http://www.ikvm.net/
  172. Re: couple of clarifications[ Go to top ]

    Apparently, you are the only one confused about VB.NET not being VB.
    It seems that Microsoft share this confusion. On their website they classify .NET versions of Visual Basic as yet another version (although with backward incompatibilities) of their Visual Basic line of products. Personally, I think that Microsoft's classification of their products is probably more definitive than yours).
  173. Re: couple of clarifications[ Go to top ]

    It seems that Microsoft share this confusion. On their website they classify .NET versions of Visual Basic as yet another version (although with backward incompatibilities) of their Visual Basic line of products. Personally, I think that Microsoft's classification of their products is probably more definitive than yours).
    I guess Microsoft's marketing department likes people like you. But I'm sure even VB6 developers aren't as confused as you.
  174. Re: couple of clarifications[ Go to top ]

    I guess Microsoft's marketing department likes people like you.
    I doubt it, as I rarely buy their development products.
    But I'm sure even VB6 developers aren't as confused as you.
    Yes, this may well be the case. Reading your posts and then Microsoft's technical notes has certainly left me confused.
  175. Re: couple of clarifications[ Go to top ]

    I doubt it, as I rarely buy their development products.
    But you're suddenly all worried about VB6?
    Yes, this may well be the case. Reading your posts and then Microsoft's technical notes has certainly left me confused
    You've probably confused yourself. It's OK, maybe there's "support" for you.
  176. Re: couple of clarifications[ Go to top ]

    I doubt it, as I rarely buy their development products.


    But you're suddenly all worried about VB6?
    I rarely buy their development products, but I occasionally work with people who do.
    Yes, this may well be the case. Reading your posts and then Microsoft's technical notes has certainly left me confused


    You've probably confused yourself. It's OK, maybe there's "support" for you.
    Please, let's try and avoid statements like this.
  177. about paying moral debts[ Go to top ]

    Cameron don't you think you have a moral obligation to all poor souls you have lured into the J2ee/Ejb quicksand? A small apology perhaps? You can use the apology-generator at karmafarm for the initial draft, adjust after need. Don't bother with any letter to me though.
  178. Re: couple of clarifications[ Go to top ]

    Where did I say that? Of course there are tools to help. The fact that you need such tools indicates that it is not trivial.
    Well, duh. It's not the same language.
    You are completely missing the point. Let me say it again. You don't have to migrate off of COBOL because it has not reached its end-of-life. There is an on-going strategy of support. Partly because it is still quite widely used, and partly because it is a multi-vendor language. This is very likely to be the future situation for Java. Microsoft has stated that there will not be continuing support for pre-.NET Visual Basic.
    Ok, back on topic then. With Mono being out there, all the handwaving about .NET going away and being stuck with "unsupported" software is pretty much irrelevant. But in reality, you can continue to program in VB for as long as you want.
    Effectively they have changed the language and told developers they had better migrate if they want continued support. Migration is not trivial.
    They didn't change the language. They made a new language. Yes, if I port my Pascal code to C++, it's not going to be trivial.
    No, they can't. They can't easily supply bug fixes or patches as VB is not multi-vendor.
    Fixes or patches aren't all there is to "support". Hell, Sun doesn't supply fixes and patches for Java right now.
    So developers only have just over 18 months left. At that point Microsoft will be able to release service patches for future versions of Windows that potentially break VB6 programs. (I am not saying that they will, just that there will be nothing to stop them). Seems like Microsoft has a different perspective on these things - which is why I'm so cautious about using their stuff.
    And sometimes people are too cautious and get left behind.
    That article may say that 6 years is "near-eternity in computer time", but many of us expect our software to be used and maintained for far longer than that.
    And it can be maintained and used for far longer than that. You just won't get Microsoft holding your hand while you're doing it. When Microsoft makes the decision to break VB apps (probably a long time off), you can keep the boxes you have now. But I don't expect Sun to fix and patch all the bugs they have either. Sometimes it's time to move on. How many win 3.1 apps are still out there and being maintained? Probably more than you think. Hell, we have a DOS app that we still supply to customers sometimes.
  179. Re: couple of clarifications[ Go to top ]

    Ok, back on topic then. With Mono being out there, all the handwaving about .NET going away and being stuck with "unsupported" software is pretty much irrelevant.
    No, it isn't. Mono isn't full .NET, and never will be. Even the authors of Mono admit that it isn't going to be able to cope with enterprise-scale server side development.
    They didn't change the language. They made a new language. Yes, if I port my Pascal code to C++, it's not going to be trivial.
    That is irrelevant. The point is that that they stopped supporting a language that was used by a very large number of developers. If you wish to label VB.NET an entirely new language, with major migration issues, that backs my case even more.
    Fixes or patches aren't all there is to "support". Hell, Sun doesn't supply fixes and patches for Java right now.
    Nonsense. Java 1.5.0 update 7 was recently released and contains a number of bug fixes.
    And sometimes people are too cautious and get left behind.
    Wrong. Being cautious and choosing the right supplier of your development products means that you are not left behind - a lesson that many VB developers who have migrated to Java have learned.
    You just won't get Microsoft holding your hand while you're doing it.
    Which is why I stick with companies that will.
    When Microsoft makes the decision to break VB apps (probably a long time off), you can keep the boxes you have now. But I don't expect Sun to fix and patch all the bugs they have either.

    Sometimes it's time to move on. How many win 3.1 apps are still out there and being maintained? Probably more than you think. Hell, we have a DOS app that we still supply to customers sometimes.
    Exactly. That is why I expect long-term support. I still support Win 3.1 apps that break under XP. I want to move on at my pace, not a pace forced by Microsoft.
  180. Re: couple of clarifications[ Go to top ]

    No, it isn't. Mono isn't full .NET, and never will be. Even the authors of Mono admit that it isn't going to be able to cope with enterprise-scale server side development.
    It isn't full .NET and doesn't need to be full .NET because it doesn't need to support all of the windowism. And please find me "the Mono authors" that admit it isn't going to be able to cope with enterpise-scale server side deployment. Gosling said that Java can't cope with enterprise-scale server side deployment. Use C++.
    That is irrelevant. The point is that that they stopped supporting a language that was used by a very large number of developers. If you wish to label VB.NET an entirely new language, with major migration issues, that backs my case even more.
    No, the point is that it's a new language, and it doesn't back your case even more.
    Nonsense. Java 1.5.0 update 7 was recently released and contains a number of bug fixes.
    Oh, so update 7 fixed all the bugs? I didn't think so.
    Wrong. Being cautious and choosing the right supplier of your development products means that you are not left behind - a lesson that many VB developers who have migrated to Java have learned.
    Wrong, knowing when it's time to leave the legacy crap behind means you won't be left behind.
    Which is why I stick with companies that will.
    If you need hand holding, then all the power to you.
    Exactly. That is why I expect long-term support. I still support Win 3.1 apps that break under XP. I want to move on at my pace, not a pace forced by Microsoft.
    I would run win 3.1 apps under the proper environment.
  181. Re: couple of clarifications[ Go to top ]

    It isn't full .NET and doesn't need to be full .NET because it doesn't need to support all of the windowism.
    I don't think you understand the issues involved here. This is nothing to do with Windows API support - it is to do with features like clustering.
    And please find me "the Mono authors" that admit it isn't going to be able to cope with enterpise-scale server side deployment.
    Sure: http://www.itwriting.com/monointerview.php "Mono is not positioned at the high end of the enterprise application market" "What is clear is that Mono (as opposed to .NET) is not currently designed for scalability or transactional distributed applications. De Icaza’s comments suggest that this is unlikely to change.."
    That is irrelevant. The point is that that they stopped supporting a language that was used by a very large number of developers. If you wish to label VB.NET an entirely new language, with major migration issues, that backs my case even more.


    No, the point is that it's a new language, and it doesn't back your case even more.
    Yes, I am afraid it does, because you can't have it both ways. In a previous post you stated that Microsoft were supplying tools to assist with the migration, so this should not be a problem. Now you claim that migration is difficult because VB.NET is an entirely different language. Which is it?
    Nonsense. Java 1.5.0 update 7 was recently released and contains a number of bug fixes.


    Oh, so update 7 fixed all the bugs? I didn't think so.
    Sorry, you have lost me here. How is this at all relevant to your claim that fixes to Java aren't being released? Perhaps you could point to any patch for any product that has fixed all bugs.
    Wrong, knowing when it's time to leave the legacy crap behind means you won't be left behind.
    Ah, so Visual Basic 6 is 'legacy crap'? I am sure that will endear you to millions of developers who have bought into Microsoft's language strategy :)
    I would run win 3.1 apps under the proper environment.
    Ah - so you would not only run apps which are no longer supported on operating systems that are no longer supported. Appropriate.
  182. Re: couple of clarifications[ Go to top ]

    Sure: http://www.itwriting.com/monointerview.php "Mono is not positioned at the high end of the enterprise application market" "What is clear is that Mono (as opposed to .NET) is not currently designed for scalability or transactional distributed applications. De Icaza’s comments suggest that this is unlikely to change.."
    Steve, it looks like you didn't read that carefully. de Icaza didn't say that, the author of the article did. Notice the absence of quotes. But then there was: "An interesting case study is the City of Munich, which decided to move entirely away from Windows onto Linux. It had an application for provisioning and human resources management that was running on ASP.NET. The company which developed the application came to Mono for help with porting. "We fine-tuned Mono, and made sure that the bugs were fixed, so by the time Mono 1.0 was released they could deploy it on 500 servers in the City of Munich. Now we’re seeing the software also deployed in the city of Berlin."
    Yes, I am afraid it does, because you can't have it both ways. In a previous post you stated that Microsoft were supplying tools to assist with the migration, so this should not be a problem. Now you claim that migration is difficult because VB.NET is an entirely different language. Which is it?
    No, wrong again. I didn't make any such claims.
    Sorry, you have lost me here. How is this at all relevant to your claim that fixes to Java aren't being released? Perhaps you could point to any patch for any product that has fixed all bugs.
    If you don't have a bug fix for the bug that you're experiencing now then it's irrelevant if patches and fixes might be made at some point in the future. You just don't know. But of course this all goes back to this meandering about VB and how the sky will be falling if Microsoft doesn't supply patches. The sky isn't going to fall if Sun doesn't fix your bug either.
    Ah, so Visual Basic 6 is 'legacy crap'? I am sure that will endear you to millions of developers who have bought into Microsoft's language strategy :)
    Hah, I'm not really interested in being "endeared" by VB6 developers. But yeah, even most VB6 developers should realize that time doesn't stand still for them.
    Ah - so you would not only run apps which are no longer supported on operating systems that are no longer supported. Appropriate.
    Oh, so now Microsoft has to support your app too? Geez, how much hand holding do you need Steve?
  183. Re: couple of clarifications[ Go to top ]

    Steve, it looks like you didn't read that carefully. de Icaza didn't say that, the author of the article did. Notice the absence of quotes.
    OK, show me a contradicting quote.
    "An interesting case study is the City of Munich, which decided to move entirely away from Windows onto Linux. It had an application for provisioning and human resources management that was running on ASP.NET. The company which developed the application came to Mono for help with porting. "We fine-tuned Mono, and made sure that the bugs were fixed, so by the time Mono 1.0 was released they could deploy it on 500 servers in the City of Munich. Now we’re seeing the software also deployed in the city of Berlin."

    Which has no relevance to the issue of Mono being suitable for high-end enterprise work, in competition with .NET and J2EE.
    Yes, I am afraid it does, because you can't have it both ways. In a previous post you stated that Microsoft were supplying tools to assist with the migration, so this should not be a problem. Now you claim that migration is difficult because VB.NET is an entirely different language.

    Which is it?


    No, wrong again. I didn't make any such claims.
    OK. So if it is an entirely different language, why would Microsoft be supplying migration tools? Please explain.
    Sorry, you have lost me here. How is this at all relevant to your claim that fixes to Java aren't being released? Perhaps you could point to any patch for any product that has fixed all bugs.


    If you don't have a bug fix for the bug that you're experiencing now then it's irrelevant if patches and fixes might be made at some point in the future. You just don't know.
    Sorry, you have lost me here. How is this at all relevant to your claim that fixes to Java aren't being released?
    But of course this all goes back to this meandering about VB and how the sky will be falling if Microsoft doesn't supply patches. The sky isn't going to fall if Sun doesn't fix your bug either.
    You are missing the point (yet again). This is not just about patches. It is about the potential for operating system changes that can break applications written in the language. Having experienced such changes with some languages, it certainly could be a 'sky fall' situation (and in some situations, it has come close to that).
    Ah - so you would not only run apps which are no longer supported on operating systems that are no longer supported. Appropriate.


    Oh, so now Microsoft has to support your app too? Geez, how much hand holding do you need Steve?
    A lot, I am afraid. I am a poor fragile developer who simply wants to be able to go back to software I wrote 15 years ago and be able to maintain it. I have written software in numerous languages. In most of them I can do this. Only with Microsoft languages and on Microsoft platforms has this been major problem.
  184. Re: couple of clarifications[ Go to top ]

    Steve, it looks like you didn't read that carefully. de Icaza didn't say that, the author of the article did. Notice the absence of quotes. OK, show me a contradicting quote.
    Steve learn to read, and then re-read the article again. It was NOT de Icaza that said that. It was the author of the article that tried to draw his own conclusions.
    Which has no relevance to the issue of Mono being suitable for high-end enterprise work, in competition with .NET and J2EE
    Actually, it has a lot more relevance than your quote that was never said by de Icaza.
    OK. So if it is an entirely different language, why would Microsoft be supplying migration tools? Please explain.
    Come on Steve, this isn't rocket science. Don't you think that Microsoft wants the transition to .NET to be easy and not hard for VB6 developers? Why is there a C to Java translator?
    Sorry, you have lost me here. How is this at all relevant to your claim that fixes to Java aren't being released?
    I never claimed that there weren't fixes and patches to Java being released. I said...I said...that if the bugs you are encountering don't get fixed then you're not jumping for joy because some other bugs got fixed.
    A lot, I am afraid. I am a poor fragile developer who simply wants to be able to go back to software I wrote 15 years ago and be able to maintain it.
    And once again, Microsoft is suppose to debug your code? Why don't you just hire a consultant if you don't have the chops to maintain the code you wrote 15 years ago?
    I have written software in numerous languages. In most of them I can do this. Only with Microsoft languages and on Microsoft platforms has this been major problem.
    And others have major problems with Java.
  185. Re: couple of clarifications[ Go to top ]

    Steve learn to read, and then re-read the article again. It was NOT de Icaza that said that. It was the author of the article that tried to draw his own conclusions.
    Presumably, if this was the case, and the author was mistaken, then de Icaza would have issued some sort of denial. You are really reaching here. Trying to that claim that something was not said by de Icaza simply because it is reported and not actually in quotes does not seem a valid point to me.
    OK. So if it is an entirely different language, why would Microsoft be supplying migration tools? Please explain.


    Come on Steve, this isn't rocket science. Don't you think that Microsoft wants the transition to .NET to be easy and not hard for VB6 developers? Why is there a C to Java translator?
    You may wish to persist in insisting that VB and VB.NET are entirely different languages, for whatever reason. It is clear from Microsoft's website that they are not. It is clear from the views of a vast number of VB developers that they are not - they are incompatible versions of the same language. I see no point in discussing this further.
    I never claimed that there weren't fixes and patches to Java being released.
    Yes you did: "Hell, Sun doesn't supply fixes and patches for Java right now."
    A lot, I am afraid. I am a poor fragile developer who simply wants to be able to go back to software I wrote 15 years ago and be able to maintain it.


    And once again, Microsoft is suppose to debug your code? Why don't you just hire a consultant if you don't have the chops to maintain the code you wrote 15 years ago?
    You are missing the point (yet again). I can support those languages from 15 years ago because they are still around in various platforms and supplied by many vendors. Hiring a consultant will be of no use at all in, say, 15 years, when it is possible that there may not be a current version of Windows that even runs VB6 applications.
    I have written software in numerous languages. In most of them I can do this. Only with Microsoft languages and on Microsoft platforms has this been major problem.


    And others have major problems with Java.
    Not the problem we are discussing. I am going to leave this discussion here - we don't seem to be making progress. Thanks for the debate.
  186. Re: couple of clarifications[ Go to top ]

    Hell, Sun doesn't supply fixes and patches for Java right now.
    They do "supply fixes and patches" for all of their distributions of Java. Even including old versions (back to JDK 1.3). In fact, they just released a service pack a week or so ago! Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  187. Re: couple of clarifications[ Go to top ]

    They do "supply fixes and patches" for all of their distributions of Java. Even including old versions (back to JDK 1.3).
    So did Sun EOL everything before JDK 1.3?
  188. Re: couple of clarifications[ Go to top ]

    They do "supply fixes and patches" for all of their distributions of Java. Even including old versions (back to JDK 1.3).
    So did Sun EOL everything before JDK 1.3?
    No, they supplied a big patch called 1.4, and a big patch to that called 1.5 ;-) The difference is that they are backwards compatible, with very few exceptions. We still use code today (unmodified) in our Coherence product that was written for JDK 1.0.2.
  189. Do you even know that C/C++ can be compiled to .NET?
    Well, sorta. You can't compile C into CLR compatible code since it lacks the OO layout needed. C++ is a hit or miss affair. Although, I don't know why someone would convert C++ to managed code since you loose serious performance.
    In any case, .NET is the future of Windows programming whether people like it or not.
    I haven't seen to many commercial applications of .NET yet. Most people shun the idea of download the .NET runtime just to run a application they bought at Best Buy. Maybe when Vista gets to market it may be an option.
    There's just no getting around it.
    I write apps that don't require the .NET that work just fine on windows.
    And since desktop linux never took off,
    Desktop Linux adoption is gaining traction. It's amazing how far they have come in a few years. Look at Ubuntu as an example. And with the new OpenGL desktops in development, it will soon outdo Microsoft.
    the client will be .NET and the browser for simpler tasks.
    Hmmm. This seems to ignore the current trend to web based applications. In this category, Microsoft's ASP technology is already starting to show its age. Atlas is a good example. I think most of the problem stems from the fact that Microsoft innovated too many technologies in to the language that it is starting to become hard for it to change with the times. Languages like Ruby and PHP are killing ASP while Java based technologies, for the most part, still remains just as popular as it was a few years ago. If ASP doesn't get some serious help its gonna fade in to obscurity.
  190. Do you even know that C/C++ can be compiled to .NET? Well, sorta. You can't compile C into CLR compatible code since it lacks the OO layout needed. C++ is a hit or miss affair. Although, I don't know why someone would convert C++ to managed code since you loose serious performance.
    Why does most of crap out there get written? Why are there a billion IRC clients on sourceforge. Who knows. Actually, according to the guys that did the port, the performance hit wasn't bad. It'd probably be better with .NET 2.0 http://www.codeproject.com/managedcpp/quake2.asp
    I haven't seen to many commercial applications of .NET yet. Most people shun the idea of download the .NET runtime just to run a application they bought at Best Buy. Maybe when Vista gets to market it may be an option.
    The difference is that almost all windows computers will have .NET and the commercial applications will be there. How much shrink-wrapped Java is there?
    I write apps that don't require the .NET that work just fine on windows.
    The win32 subystem will be there for years to come. Duh. Microsoft realizes they can't get rid of it overnight. The point is that .NET will (if not already) the preferred way to write desktop applications on Windows. Vista pretty much seals the deal on that.
    Desktop Linux adoption is gaining traction. It's amazing how far they have come in a few years. Look at Ubuntu as an example. And with the new OpenGL desktops in development, it will soon outdo Microsoft.
    That's what we hear every year:) At the rate it's going now it'll be another half-century before they get to 10%. I'd look to OSX taking a bite out of the windows desktop market before Linux does. There's just way too much fragmentation on Linux.
    Hmmm. This seems to ignore the current trend to web based applications.
    DHTML(Ajax included) is broken as a real application delivery vehicle, no matter how much server-side guys want to wish otherwise. Flash is a bit better, but it has its own issues. Sorry, but a dumb web terminal isn't going to take over the world.
    In this category, Microsoft's ASP technology is already starting to show its age. Atlas is a good example. I think most of the problem stems from the fact that Microsoft innovated too many technologies in to the language that it is starting to become hard for it to change with the times.
    Except millions of programmers use it just fine. Let's not get started on all the crap that Sun has inflicted on people. And you're talking about languages. Sun doesn't do anything with theirs except for the occasional rip-off of some C# feature.
    Languages like Ruby and PHP are killing ASP while Java based technologies, for the most part, still remains just as popular as it was a few years ago. If ASP doesn't get some serious help its gonna fade in to obscurity.
    Hehe, sure. That's why you get a hordes of Java programmers having a mental meltdown everytime RoR is mentioned.
  191. I've been trying desktop linux about once every two years. So far I'm not convinced. The last I tried was Fedora Core 4 on my laptop. It didn't do CPU throttling correctly and sleep/resume didn't work either. I messed around with it for a week in ways no regular user would ever be able to do. I got everything running but the result was still awful. Throttling didn't react quickly enough to changes in CPU load and sleep/resume crashed the machine more often than it worked.
  192. Except your analogy doesn't make sense. You do realize that this isn't 2001 and they've already done it, don't you? Maybe this stuff is complicated for you, but not for other people. It's as simple as "We're going to use C# for this project", or "we're going to use VB.NET for this project.
    Right and everyone has upgraded from Windows 98 to XP...
  193. Except your analogy doesn't make sense. You do realize that this isn't 2001 and they've already done it, don't you? Maybe this stuff is complicated for you, but not for other people. It's as simple as "We're going to use C# for this project", or "we're going to use VB.NET for this project. Right and everyone has upgraded from Windows 98 to XP...
    Right, and everyone has upgraded from Win3.1, or even DOS.
  194. Except your analogy doesn't make sense. You do realize that this isn't 2001 and they've already done it, don't you? Maybe this stuff is complicated for you, but not for other people. It's as simple as "We're going to use C# for this project", or "we're going to use VB.NET for this project.



    Right and everyone has upgraded from Windows 98 to XP...


    Right, and everyone has upgraded from Win3.1, or even DOS.
    Well according to the last number I heard, there are a LOT of corporation still using Windows 98 and not XP. I know where I work they switched like one year ago.
  195. Well according to the last number I heard, there are a LOT of corporation still using Windows 98 and not XP. I know where I work they switched like one year ago.
    Maybe 98 wasn't as bad as everybody made it out to be. And please quantify "a LOT". But to say, as the OP stated, that there isn't a lot of .NET development being done is retarded.
  196. Well according to the last number I heard, there are a LOT of corporation still using Windows 98 and not XP. I know where I work they switched like one year ago.


    Maybe 98 wasn't as bad as everybody made it out to be. And please quantify "a LOT".

    But to say, as the OP stated, that there isn't a lot of .NET development being done is retarded.
    The point is that I think it is VERY optimistic of you to pretend Microsoft developers have almost all migrated to .Net back in 2001. Well from my experience it isn't true at all. But hey who am I to pretend such things?
  197. The point is that I think it is VERY optimistic of you to pretend Microsoft developers have almost all migrated to .Net back in 2001. Well from my experience it isn't true at all. But hey who am I to pretend such things?
    Who said that Microsoft developers have almost all migrated to .NET back in 2001? Stop imagining things. But it is the OP who is pretending that there isn't a lot of .NET development.
  198. But the idea of unifying the mess of Visual Basic and Windows API programming by creating a completely new, ground-up programming environment with not one, not two, but three languages (or are there four?) is sort of like the idea of getting two quarreling kids to stop arguing by shouting "shut up!" louder than either of them. It only works on TV. In real life when you shout "shut up!" to two people arguing loudly you just create a louder three-way argument."
    Except your analogy doesn't make sense. You do realize that this isn't 2001 and they've already done it, don't you? Maybe this stuff is complicated for you, but not for other people. It's as simple as "We're going to use C# for this project", or "we're going to use VB.NET for this project.
    So what did you mean there? That people have started to make those decisions back in 2001 and know how to make it now? If it's the case well sorry I misinterpreted your statement. After all english isn't my native language.
  199. They refers to Microsoft.
    But the idea of unifying the mess of Visual Basic and Windows API programming by creating a completely new, ground-up programming environment with not one, not two, but three languages (or are there four?) is sort of like the idea of getting two quarreling kids to stop arguing by shouting "shut up!" louder than either of them. It only works on TV. In real life when you shout "shut up!" to two people arguing loudly you just create a louder three-way argument."
    So what did you mean there? That people have started to make those decisions back in 2001 and know how to make it now? If it's the case well sorry I misinterpreted your statement. After all english isn't my native language.
    They refers to Microsoft. The OP seems to be in some time warp where it hasn't been done....5 years ago. And obviously, some bizarre analogy to quarreling kids on TV is well....misguided, saying it nicely.
  200. Right, and everyone has upgraded from Win3.1, or even DOS.


    Well according to the last number I heard, there are a LOT of corporation still using Windows 98 and not XP. I know where I work they switched like one year ago.
    Hey, I know places that still use DOS applications (and they work well)...
  201. Wow... one of the longest threads. It's zen-like stuff: :P (1) One's strengths often reflect one's weaknesses (e.g., don't let your children to have too much freedom, etc.). (2) Too open is as worse as closed (mind, character, framework, etc.). (3) It is hard to make changes in one's life (life style, behavior, programming platform, etc.).
  202. .Net[ Go to top ]

    So... you have non-technical people making company-wide technical decisions at the project level. And... you are mostly writing web-apps that sit on databases. I guess it could be worse :) But seriously: -"Too much choice" is not an excuse to avoid a technology. It's an opportunity to tailor it to your company's needs. If *you* can't make those choices for frameworks, IDEs, middleware severs etc, then someone in your company should be able to. If not, then you will get a bunch of non-technical people making those choices for you. They will likely be the of the "Please spoon-feed me Mr. Vendor" variety. The spoon-feeding ends up being restrictive if you decide to break away from it -- and usually expensive. -.NET has a *LOT* of implications that the Java platform simply does not have. Don't like the IDE? Too bad. Don't like the OS? Too bad. Don't like the web-server? Too bad. Microsoft died a horrible death? Too bad; there go your eggs. Haven't kept up on Mono, but I'm not sure that's a full-blown solution. -Linux on Dell (or equivalent cheap OS on commodity boxes) WILL visit your company soon. When it does, the non-technologists in your company will have "another great idea" and you'll be saying "Umm, no we need to re-write that app for a non-Windows platform". -CRUD apps sitting on databases are not really a Java vs. .Net worthy topic. You might want to try Ruby on Rails or HTMLDB or some other technology if all you want is a DB babysitter.
  203. I think on the whole the debate thus far as been a good one. One angle I wanted to bring up is to do with the identity or "branding" of Java as an enterprise development platform. What is Java good for? With the demise of EJB's and App Servers, I'm not sure whether the answer to this question is clear to most Managers. Once upon a time Java was the "Write one run anywhere" language, which fitted in with the idea of "The network being the computer" and coporate IT system integration. With the abondoment of mobile and remote objects by Sun (JINI, JavaSpaces, RMI, IIOP, etc) then there doesn't seem to be a clear vision or purpose any more. I agree with a point made by many that Java as the enterprise integration platform is an "indentity" for Java that I recognise and makes sense, but this identity leaves scope for many alternatives. Sun has played the Marketing game with Microsoft, chasing down the "Internet is everything" path with things such as SOAP and WS-*, and in so doing IMO lost any sense of focus an identity for Java as an enterprise platform. For simple CRUD web apps I would consider .NET. I know very little about it but it does seem to have a clearer lable on the box. For true large scale, distributed, enterprise wide, component based application development IMO Java (EJB's) have largely failed and I'm holding out hope for scripting languages as enterprise component glue (through IoC Containers and Java Components perhaps) or perhaps fully dynamic enterprise wide distributed OO solutions using dynamic, late-bound languages like Ruby or even Smalltalk, who knows. I think the simple answer is to select the right (simplest) tool for the job. IMO for a new programmer who hasn't and doesn't want to invest many man years of effort learning all the JAVA API's the right (simplest) tool for a lot of jobs out there isn't necessarily Java. Also for the developer willing to develop skills in a number of languages, significant advantage can be gained by not having to rely on Java for everything. Paul.
  204. Paul, For the most part, I agree fully with your post.
    With the demise of EJB's and App Servers, I'm not sure whether the answer to this question is clear to most Managers.
    While I praise the demise of EJB's, I wouldn't agree that there's a similar demise of app servers. What they have become is a commodity like database engines. Oracle, Sybase, DB2, MS SQL Server, MySQL, etc. all perform the same basic functions and adhere to the SQL-92 standard, and each has its own slight differences. When I go to a new client, I don't particularly care what DBMS they're using since there isn't a huge difference from a Java developer's perspective. The same now applies to app servers. I can go into a client and work with WebSphere, JBoss, Tomcat (without EJB's!), EAServer, etc. without a whole lot of heavy lifting in terms of differences between the products. That, IMHO, is a good thing!
    For simple CRUD web apps I would consider .NET.
    And...
    I think the simple answer is to select the right (simplest) tool for the job. IMO for a new programmer who hasn't and doesn't want to invest many man years of effort learning all the JAVA API's the right (simplest) tool for a lot of jobs out there isn't necessarily Java. Also for the developer willing to develop skills in a number of languages, significant advantage can be gained by not having to rely on Java for everything.
    I agree that relying on Java for everything is not a good idea. So is relying on C# for everything! ;) I keep hearing about "simple CRUD apps". Sure the initial intention of an application may have been a simple CRUD app, but how often do those "simple" apps become extended well beyond their initial scope over time? This goes back to my point that, regardless of language, good OO design principles and practices are required for any system, even these so-called simple ones. Once you try to extend a system that has been hacked together quickly, code rot sets in and eventually it becomes more cost-efficient to rewrite an application rather than extend it. The IT industry could save enormous amounts of money if people built even the simplest systems correctly in the first place. That implies a couple of things: the developers have to understand OO principles (beyond just inheritance!), and they have to invest some time and effort in initial releases to lay the foundation for further maintenance. That doesn't mean to code in a generalized manner, but it does mean that they have to write code that has tests, has no duplication, and fully expresses its intent through package/class/method names. What we have seen up to now are "simple" applications that are highly coupled, have little cohesion, are very brittle, and generally have few if any automated tests. Tools such as Visual Studio and predecessors like VB attempt to focus the developer on building the interface, which leads to high coupling of presentation and business logic. Combine that with developers that don't understand why business logic in the presentation is a bad thing, and you have the many, many thousands of crappy applications in existence today. I don't reserve all my criticism for M$ either. Java frameworks such as Struts actively encourage the developer to put logic in the form beans for populating from the domain layer and performing validation. Before anyone argues that such coupling isn't that, ask yourself this question: what happens if I need to write a Swing front-end for the same application, with the same business rules to be applied? Dave Rooney Mayford Technologies http://www.mayford.ca
  205. Hi Dave,
    I keep hearing about "simple CRUD apps". Sure the initial intention of an application may have been a simple CRUD app, but how often do those "simple" apps become extended well beyond their initial scope over time? This goes back to my point that, regardless of language, good OO design principles and practices are required for any system, even these so-called simple ones.
    I agree fully with your post too. True OO has been badly mis-represented by languages like C++ and is largely mis-uderstood by most developers. Infact there are many that believe that OOP has reached its limits and we need to look to things like AOP as the next big thing. It makes me livid. Sadly we work in an industry where using the latest buzz technology is seen as more important than having good people. Fortunately the Agile movement is beginning to change this mindset, but I guess it will just take time.
    I don't reserve all my criticism for M$ either. Java frameworks such as Struts actively encourage the developer to put logic in the form beans for populating from the domain layer and performing validation.
    IMO Sun is applying a similar technology policy as M$. They deliver technology that is easy to sell. Telling someone that they can leverage their existing incumbent technology makes for an easy sale, so we build sh*t on top of sh*t (think WS-* and AJAX). Also we never throw anything away (think EJB2->EJB3), and we define premature standards based on untried and unproven technology for commercial reasons (think JSF). Personally, I'm placing my hope on open source. Incidently many of the best open source ideas aren't emerging from Java or C#, but from dynamic, pure OO languages like Ruby, Python and Smalltalk. With any luck our futures could be very different from our recent past. Imagine finally getting to use a pure OO language in your day job! Paul.
  206. IMO Sun is applying a similar technology policy as M$. They deliver technology that is easy to sell. Telling someone that they can leverage their existing incumbent technology makes for an easy sale, so we build sh*t on top of sh*t (think WS-* and AJAX).
    Of course they both deliver technology that is easy to sell. How could it possibly make sense for company to deliver technology that is not easy to sell! However, anyone who has studied Sun and Microsoft technologies for any period realises that they have different strategies. Microsoft has always (it seems to me) gone for many technologies largely to sell whatever makes developers happy short-term, often neglecting well-established principles. The classic example of this was Bill Gates praising Smalltalk in the late 80s, then delivering inheritance-lacking Visual Basic (something the not-yet OOP literate general developer community could deal with) and now we see a 'let's throw everything in' approach to .NET languages, even when such an approach has led to language bloat in the past. I don't think that anyone with a long-term understanding of the history of the companies and their products could honestly say that Sun has a similar technology policy to Microsoft.
    and we define premature standards based on untried and unproven technology for commercial reasons (think JSF).
    No, actually - don't think JSF in this role; it is a poor example of this. JSF was (as has already been pointed out in previous threads) based on established approaches, and its flexibility and friendliness to 'non-commercial' approaches is well illustrated by projects like facelets (I find the combination of facelets and the MyFaces tomahawk components incredibly productive) and seam. I would go along with you regarding EJB 3.0 (which could have been so much better), but certainly not JSF.
    Personally, I'm placing my hope on open source.
    Well Sun's decision to open source Java at some point should add to that hope :) I think this shows that simply going for an approach of 'open source' is not a useful criterion - does Java suddenly become better simply because it is open source?
    Imagine finally getting to use a pure OO language in your day job!


    Paul.
    I did, with Smalltalk years ago. I found serious performance and maintenance consequences of doing this. I switched to Java.
  207. Hi Steve, Nice to hear from you. I agree with much of what you say. My main points were aimed at Java as an enterprise platform, rather then at Java as a programming language:
    However, anyone who has studied Sun and Microsoft technologies for any period realises that they have different strategies. Microsoft has always (it seems to me) gone for many technologies largely to sell whatever makes developers happy short-term, often neglecting well-established principles.
    It would be unfair of me to imply that as far as language design goes Java is as bad as say Visual Basic, but as a platform J2EE has become some what of a swiss army knife over recent years. Your reference to "short-term, often neglecting well-established principles" can easily be applied to many of the WS-* standards that have emerged over recent years. Much of this stuff just will never deliver on the promises made to niave architects and IT strategy types.
    MyFaces tomahawk components incredibly productive) and seam. I would go along with you regarding EJB 3.0 (which could have been so much better), but certainly not JSF.
    OK. I won't argue this point as I clearly agree that EJB3.0 clearly falls into this camp. Having said this I'm sure that a non "design by committee" approach to JSF could have lead to a simpler solution. I know that much as been done to simplify JSF (you mention MyFaces and Tomahawk, which I believe are open source), but would that have been needed if JSF was simple in the first place? Look at the design of Wicket. I do need to gain hands-on experience with JSF before dismissing it, but quite frankly the spec. has really put me off.
    Well Sun's decision to open source Java at some point should add to that hope :) I think this shows that simply going for an approach of 'open source' is not a useful criterion - does Java suddenly become better simply because it is open source?
    This would be great. First of all changes to the VM could be made to provide a better meta model, hopefully reducing the need for XML and Annotations for this purpose. Also adding AspectJ semantics straight into the language would improve the meta capbablities even further. Having said all this my main criticism isn't of the language. You've got to admit that J2EE as a platform does have an identity crisis. What does it do? what is it for? what is the central theme? The answer to these questions use to be a distributed component model using EJB's. What is the answer today? I don't know much about .NET, but I don't think it suffers from this identiy crisis. This is important in corporations because they tend to like to use different tools for different kinds of problems. I've seen this with Java and C++. The challenge then is to integrate these technologies, which incidently Java and J2EE is very good at.
    I did, with Smalltalk years ago. I found serious performance and maintenance consequences of doing this. I switched to Java.
    Understood, and you probably had good reason. But the world has moved on, and at a minimum I see a role for dynamic scripting languages as a means of scripting together static enterprise components. Put it this way using say Ruby as enterprise component glue has got to be a lot better than relying on XML. How else will we be able to up the level of abstraction within the enterprise? Paul.
  208. Hi Steve,

    Nice to hear from you.
    And you.
    Your reference to "short-term, often neglecting well-established principles" can easily be applied to many of the WS-* standards that have emerged over recent years. Much of this stuff just will never deliver on the promises made to niave architects and IT strategy types.
    I am not knowledgeable enough about web services to comment, but I have no reason to doubt you.

    OK. I won't argue this point as I clearly agree that EJB3.0 clearly falls into this camp. Having said this I'm sure that a non "design by committee" approach to JSF could have lead to a simpler solution. I know that much as been done to simplify JSF (you mention MyFaces and Tomahawk, which I believe are open source), but would that have been needed if JSF was simple in the first place? Look at the design of Wicket. I do need to gain hands-on experience with JSF before dismissing it, but quite frankly the spec. has really put me off.
    Don't let it! JSF provides a rich platform for extensions because of the complexity of its internal workings, but this does not mean it is complex for developers to use. The richness of its internals allows frameworks like Facelets and Seam to be developed. It allows developers to easily add extensions to the framework. (I know this because I have been working on my own extension to JSF - which I intend to release soon). There is also a large set of commercial and open-source components available. I think Sun made a big mistake with the initial marketing of JSF by emphasising all this internal complexity.
    First of all changes to the VM could be made to provide a better meta model, hopefully reducing the need for XML and Annotations for this purpose. Also adding AspectJ semantics straight into the language would improve the meta capbablities even further. Having said all this my main criticism isn't of the language.
    I think you may be being overly optimistic here! Just because Java is open source, does not mean that the language can change.
    You've got to admit that J2EE as a platform does have an identity crisis. What does it do? what is it for? what is the central theme? The answer to these questions use to be a distributed component model using EJB's. What is the answer today?
    I don't think it has an identity crisis; perhaps the issue is that it has too many identities! There are EJBs, messaging, security, servlets, JSP and now JPA and JSF.
    I don't know much about .NET, but I don't think it suffers from this identiy crisis.
    Perhaps you should look back to the huge confusion about what .NET actually was when it was first introduced!
    I did, with Smalltalk years ago. I found serious performance and maintenance consequences of doing this. I switched to Java.


    Understood, and you probably had good reason. But the world has moved on, and at a minimum I see a role for dynamic scripting languages as a means of scripting together static enterprise components. Put it this way using say Ruby as enterprise component glue has got to be a lot better than relying on XML. How else will we be able to up the level of abstraction within the enterprise?

    Paul.
    I am moving slowly towards your view of how 'scripting' languages can be used in this way; I see great potential for JRuby, which is showing a lot of progress.
  209. To make a precision, all VS2005 products come with msbuild that's essentially a build tool like ant/nant (on the comment there was no nant in VS), on the other hand there is no tool like maven2 for .Net and there is just not enough choice (of frameworks, libraries, alternative approaches) in that arena. That said, I think the enterprise can only benefit from using both Java and .Net. Both worlds have something to offer.
  210. Re: My 2 cents and a precision[ Go to top ]

    To make a precision, all VS2005 products come with msbuild that's essentially a build tool like ant/nant (on the comment there was no nant in VS), on the other hand there is no tool like maven2 for .Net and there is just not enough choice (of frameworks, libraries, alternative approaches) in that arena. That said, I think the enterprise can only benefit from using both Java and .Net. Both worlds have something to offer.
    The old build tool with VS.NET 2003 was god aweful. Comparing ANT or NANT to the old build tool is rather unfair to MS. I hear the new team system tools are much better than the old one, but I haven't used it. considering how much a full VS.NET license costs, I can't afford it. Open source java fits my price point much better :) peter
  211. MSBuild: the free .NET Ant[ Go to top ]

    I hear the new team system tools are much better than the old one, but I haven't used it. considering how much a full VS.NET license costs, I can't afford it.
    Whether you can afford a tool or not depends of course on the project budget, I think many multi-developer, distributed systems can allocate the money for Visual Studio Team System and Team Foundation Server. But, yes, many other project don't have the budget, so you can use MSBuild, the very Ant-like solution builder that comes as part of the .NET Framework, don't need Visual Studio at all, and it's free. There's even an open initiative for creating specialized tasks for MSBuild here.
  212. Re: MSBuild: the free .NET Ant[ Go to top ]

    I hear the new team system tools are much better than the old one, but I haven't used it. considering how much a full VS.NET license costs, I can't afford it.
    Whether you can afford a tool or not depends of course on the project budget, I think many multi-developer, distributed systems can allocate the money for Visual Studio Team System and Team Foundation Server. But, yes, many other project don't have the budget, so you can use MSBuild, the very Ant-like solution builder that comes as part of the .NET Framework, don't need Visual Studio at all, and it's free. There's even an open initiative for creating specialized tasks for MSBuild here.
    So far the .NET ports of open source java stuff has been good. Log4Net, Nunit, NAnt and a few others. I haven't tried MSBuild, but I already know ANT so it's something I'm already familiar with. My totally bias opinion :) peter
  213. I am disappointed that so many companies are still coding in C++ and have not made the move to either Java or C#. After coding in Java or C# going back to C++ is primitive. For software companies, Java is the way to go as you can ship your product to the maximum number of platforms. I don't think Microsoft will be able to repeat any monopoly markets again like Windows and Office, so Java and .Net will co-exist. J2EE has not been as successful as Java maybe because it was designed to protect the vested interests of the Application Server players rather than push software innovation forward.
  214. I am disappointed that so many companies are still coding in C++ and have not made the move to either Java or C#.
    After coding in Java or C# going back to C++ is primitive.
    When I came to Java from C++ my feeling was exactly the other way round - Java being primitive. And I still miss a lot of features of C++. But I think the language front is not the reason for companies hanging on to C++. There are a lot of different reasons: * Java hasn't had a way to write GUIs without eating all the memory a machine has. Hardware is only now coming along but these things take time. Not long ago you couldn't run more than a single Swing app on a typical machine. * C++ has been more portable in the sense that it didn't commit you to either Microsoft or the other camp as far as the non-GUI parts are concerned. This is important for ISVs. * Java is awful for numeric and heavily algorithmic applications. And Java's advantages for high level application development are not that important for this stuff. You don't need or even want garbage collection for purely algorithmic stuff. * And then of course there are embedded systems and Unix/Linux systems programming. Both are staunchly C/C++ constituencies. * The most important reason, however, is that you don't simply buy into a language/platform. You buy into a culture and you buy into a job market. For example, financial industries will prefer people with deep C++ knowledge because they know these people are more likely to be able to solve hard algorithmic/numeric problems. Java/J2EE types are associated with web-frontends, data access, some integration and messaging, ideally with solid OO design knowledge and with a kitchen sink of frameworks that basically do the same thing. If you're looking for someone who can contribute to a risk-management system or a vehicle routing algorithm, you're more likely to find him by asking for C++. But things are changing ... slowly. If you look at job market statistics you see that C++ is slowly coming down from a very high level. I believe this is mainly due to MFC GUI apps moving to C# and to a lesser degree due to algorithmic stuff moving to Java as Java's performance has now become very good.
  215. * Java hasn't had a way to write GUIs without eating all the memory a machine has. Hardware is only now coming along but these things take time. Not long ago you couldn't run more than a single Swing app on a typical machine.
    Not true. However, you could say that it has been much more difficult to build a nice looking and memory-efficient GUI application.
    * C++ has been more portable in the sense that it didn't commit you to either Microsoft or the other camp as far as the non-GUI parts are concerned. This is important for ISVs.
    From a brief study I did in 1996, I estimated that the cost for developing for just 16- and 32-bit Windows using C++ was 10x the cost of developing in Java. Cross-platform in C++ is possible, but extremely expensive.
    * Java is awful for numeric and heavily algorithmic applications.
    Correct on the numeric side. We (not just putting the responsibility on Sun, but "we all") need to fix this.
    * And then of course there are embedded systems and Unix/Linux systems programming. Both are staunchly C/C++ constituencies.
    Strangely, a good chunk of embedded is going to Java now.
    * The most important reason, however, is that you don't simply buy into a language/platform. You buy into a culture and you buy into a job market. For example, financial industries will prefer people with deep C++ knowledge because they know these people are more likely to be able to solve hard algorithmic/numeric problems. Java/J2EE types are associated with web-frontends, data access, some integration and messaging, ideally with solid OO design knowledge and with a kitchen sink of frameworks that basically do the same thing. If you're looking for someone who can contribute to a risk-management system or a vehicle routing algorithm, you're more likely to find him by asking for C++.
    Basically *all* the new risk systems are being done in Java. I know it's crazy (considering you only have "double" and "BigDecimal", both of which suck), but it's true. I know it's true because we're working with about 20 of the biggest banks and equities firms in the world that are either already in production with risk systems in Java, or moving there quickly.
    Java's performance has now become very good.
    For the simple stuff, yes. But you're right on the numeric stuff -- it's got to improve. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  216. Basically *all* the new risk systems are being done in Java. I know it's crazy (considering you only have "double" and "BigDecimal", both of which suck), but it's true. I know it's true because we're working with about 20 of the biggest banks and equities firms in the world that are either already in production with risk systems in Java, or moving there quickly.
    This is very far from the truth. I'm working with many of the same folks you are, and almost all of the global investment banks have strong C++ requirements and often C# (believe it or not!) on the grid. C++ has been held back because of the lack of native C++ data grid products, and we all now know that the key to scaling a grid is to eliminate data starvation. JNI Bridged Java/C++ solutions are sometimes ok but have significant shortcomings in many finserv grid use-cases. After 18 months of intense development and requirements-gathering from various clients in the grid world, GemStone recently made the first version of an all-C++ data grid/data fabric solution available--GemFire C++. On another note . . . Though my history is all in OOP, Java and DB's and I have generally stayed clear of Microsoft in my career, we just had a use-case where .NET's ability to efficiently integrate with C++ was a big plus. It allows us to support C# cluster members without JNI overhead, no native C# implementation, and relatively little work. Cheers, Gideon GemFire-The Enterprise Data Fabric http://www.gemstone.com
  217. Arguments?[ Go to top ]

    Neil, Forgive me for my English.... As mentioned before, i'm not sure if you are in the position to convince The Board. If you are, you should try speeking in their own language. There is a fundamental difference between .Net and Java. .Net is a Windows product, Java is a specification voor platforms. The first argument should therefore follow from your company's infrastructure. Another main difference is choices, i would rather speek of 'options'. Yes, there is an advantage in Java in terms of options, but this can be a risk. Try to avoid the focus on 'choices'. ROI is the keyword. If you invest in Hibernate and after a year it doesn't seem 2 do it for you, you have a few other options but you'll lose your investment in Hibernate. This is were Java options can be expensive. The main focus could be JSE and JEE to avoid these costs. .NET development i've seen looks a lot like 4GL and procedural programming. Java is mainly OO. Maybe you can find some arguments in OMT and UML books. The options in choosing a Application Server is a main advantage of the Java platform. It follows the essence of Java. This should be an argument for Java. You will be losing your investment in maintenance, but not in development by selecting another application server. I've seen situations where companies changed there platform (Windows -> Linux) of appserver (Websphere -> Oracle) because of performance, security or commercial issues without 2 many problems. I would like 2 see how you are going 2 change IIS or Windows Server 2003 in a .NET environment. Its not the building, but the system that counts. Tools like ANT, JUnit, JCoverage are easy 2 learn but greatly improves the quality of your system. You'll need just 1 lead developer to understand these concepts and defend them in project management. Hope it helps and good luck.
  218. I think this shows the need for strong jee standards. Companies shouldn't have to consider all the alternative frameworks when choosing jee, the j2ee standard should be competative to .net by in itself. It should be complete without the need for extra frameworks. Open source projects should be a sandbox/laboratry where cool new things are tried. These things should be incorporated into the standards when proven useful.
  219. I think this shows the need for strong jee standards. Companies shouldn't have to consider all the alternative frameworks when choosing jee, the j2ee standard should be competative to .net by in itself. It should be complete without the need for extra frameworks.

    Open source projects should be a sandbox/laboratry where cool new things are tried. These things should be incorporated into the standards when proven useful.
    +1 I totally agree. Not sure how it would work in practice though. The J2EE community includes commercial vendors. I'm not sure how they could compete with JCP ratified open source standards whose implementations found their way out of the sandbox into full blown production use. I guess they could use the JBoss model and offer support and consulting services, or they could get into adding additional "non-standard" features. My feeling is that from the beginning J2EE has been dominated by vendor interests and has had the dilemma of allowing commercial competition, whilst maintaining universal standards. Many of the most promising new ideas (e.g. light weight containers, JVM scripting languages etc) will mean vendors ditching their incumbent installed customer base. If they can't offer new features as complimentary to their existing product to existing customers then they will end up having to compete head on with open source implementations of JCP ratified standards. This is the reason IMO why EJB3 has been shackled with all the baggage of EJB2.1 which the vendors have implemented and where they have a large installed base. The advantage Microsoft has got is that they can ditch their past and re-invent themselves when ever they like since they seem to have a near development tool monopoly on the windows platform. This dilemma in J2EE has been there from the inception IMO. Languages like C, C++ came from the research community and the standard language was never really "owned" by vendors. Languages like Squeak and Ruby belong to their development community so are free from vendor interests too. Java and J2EE seem dominated by big vendors like Sun, BEA, IBM, Oracle etc. I just can't see these vendors giving up this position of dominance lightly, after all their primary responsibility is to their shareholders not to the Java development community. I guess they could be made to truly compete amongst themselves rather than agreeing on cosy "design-by comittee" standards up front. Us the developer community could then deciding which commercial/open source solution (or combination of solutions) to ratify as the JCP standard once they all had been tested in the market. If this was the case, then the vendors would be forced to put their research budgets to some good use and actually innovate. Paul.
  220. The advantage Microsoft has got is that they can ditch their past and re-invent themselves when ever they like since they seem to have a near development tool monopoly on the windows platform.
    I wouldn't call this a benefit, but rather a risk. Just look how MS is tieing DirectX10 to Vista: MS is surely using their dominance to make "hardcore gamers" upgrade their OS to keep having the latest and greatest, and given the big entertainment and gaming markets, this will revert to big $ for MS just on "mandatory" new OS licenses/upgrades. Although it may sound absurd and not enterprise related, this is a *very* profitable niche market, and it shows how MS operates when/where it has a clear domination. MS only did the infamous VB to VB.Net wreckage for this simple reason: VBers don't have any other option, either upgrade or be left behind, so this monopoly is an advantage to MS shareholders only, but may be detrimental to their customers. Making things short and simple: choosing .Net is like signing your next OS upgrade check in advance. ;)
  221. The management of my group, who are not technologists, has decided to embrace .NET wherever possible for our applications. They cite that Java applications take longer and run into more significant problems than their .NET counterparts.

    [Most developers] are happy to move to .NET. Apparently, Java is just too hard and too intimidating, especially for beginners.

    Java and .Net are comparably powerful technologies.

    I am amazed that no poster has mentioned the primary difference between .Net and Java. The former runs only on M$ Windows, a family of OS's that has been repeatedly proven to be completely insecure. Furthermore, the design of the Windows OS's is such that they are likely never to be secure. A related point is that even the anti-viral software used on Windows often contains security vulnerabilities (SV's), providing still another avenue of attack to crackers. Additionally, M$'s patch management (PM, its system for patching SV's) is completely rudimentary as compared to, say, Debian or Gentoo. For example, M$'s PM does not patch the software of other vendors, such as those who make anti-viral software or other "anti-malware" software.
    I would like to know why so many software developers think that this issue, security, carries so little weight in this debate, .Net versus Java. I suspect that the reason is that most software developers know so damned little about security. In fact, I have never met a Java developer who knew the difference between a buffer overflow and a stack smash, between Netfilter and iptables, or between Nessus and nmap. And I am certain that .Net developers are even more ignorant.
    Here is a proposal. Tell your management that they should not move to .Net because it runs only on an OS that is likely never to be secure.
    --Paul Bain
    Using Linux since 1997
  222. Even if windows might be hard to secure, a good (aka experienced) system administrator will know what steps to take to secure the production systems. I've seen fairly relaxed security and very anal security. Anal security practices can secure the servers even if the OS has vulnerabilities. Of course it makes it a complete pain to update the servers and doing simple things is hard. For example, in a previous job, I only allowed SSH into the servers from a specific set of IP's. Even then, only the system admin had the password. If we needed to update the servers, the sys admin would login and then pull the build from the staging environment. Once the build was uploaded to the production servers, the entire app would get compiled, deployed and tested. so honestly, for me security is not a major issue with good sys admins. With bad admins, nothing will be secure anyways. peter
  223. Paul Bain wrote:
    I am amazed that no poster has mentioned the primary difference between .Net and Java. The former runs only on M$ Windows, a family of OS's that has been repeatedly proven to be completely insecure. Furthermore, the design of the Windows OS's is such that they are likely never to be secure.
    Paul, perhaps the reason security hasn't been mentioned is because it isn't an issue? Please realize that security at Microsoft has become a criticaly important feature, and much is being done to prevent security holes througout design, coding and testing. An excellent book on the subject is _Writing Secure Code_, written by two Microsoft engineers, and it details the level of effort that is put into preventing security problems at Microsoft. Some simple, non-scientific numbers suggest that Microsoft is actually more secure than linux. From the vulnerabilities listed at http://www.securityfocus.com/vulnerabilities, I simple counted the # of vulnerabilites reported for differnt vendors from 02/21/2006 until today. (date randomly chosen to illustate a point) RedHat 309 SuSE 259 Microsoft 65 Sun 55 Apple 47 Oracle 7 According to this reputable security source, Microsoft has about 1/5th of the vulnerabilities reported for RedHat during the last 3 months. So, you were saying that the design of windows would never allow it to be secure. What is it about the design that is flawed? And why does this data suggest a different story?
  224. According to this reputable security source, Microsoft has about 1/5th of the vulnerabilities reported for RedHat during the last 3 months.
    If your life depended on it being secure, everyone knows which one you wouldn't pick ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  225. Linux[ Go to top ]

    Is Windows succumbing to Linux in your organization? At the end of the day, it doesn't matter if the answer is yes or no for the Java platform. But it certainly does matter for the .Net platform. Maybe my current company is progressive or crazy, but Windows is getting chucked for Linux on every front -- including for multi-million dollar ERP systems. I'm not about to tell our Enterprise Architect that he needs to keep a virus incubator in his rack because I wrote a C# app instead of a Java app.
  226. the beast, keep it out![ Go to top ]

    My thoughts. I would have disagreed more in my post, but everyone else is going a good job of that already.... http://adam.404.org/2006/05/27/can-you-keep-the-net-beast-out/
  227. All the points mentioned by you on j2ee products , are correct. You had carefully mentioned that your organization deals only with Intranet environment and does not have scalability problems. But if you want Enterprise container services , then EJB-3 is the way to go. In web-tier, ASP.net is very elegant and easy to learn and use. JSF is a horror. Imagine, creating a class for each form. No such trouble in ASP.net. But ASP.net is not suitable for Enterprise tier . or Messaging environments. Microsoft themselves have admitted so much in the last Java One conference. They now promote XML webservice as a client for EJB. I suggest that you talk to your colleagues and educate them about all these points. I would also request all J2ee hands to gain some basic experience in ASP.net using DotNet Framework SDK to really appreciate the wonderful technology behind ASP.net webforms. Particularly, I would request Suleiman Hani who is now in JCP to fight for developing ASP.net webform clone , yet to be developed by the JCP. I am afraid that unless this is done, the web-tier in J2ee will be losing its place definitely to ASP.net.
  228. JSF is a horror. Imagine, creating a class for each form. No such trouble in ASP.net.
    Huh? What in the world are you talking about? Are you somehow confusing Struts with JSF? I'm getting so tired of people bashing JSF who apparently know absolutely nothing about it.
  229. about JSF[ Go to top ]

    "Are you somehow confusing Struts with JSF? I'm getting so tired of people bashing JSF who apparently know absolutely nothing about it." No. I am not confusing Struts and JSF. I am comparing asp.net webforms with JSF. I have worked in Struts, ASP.net(c#) and JSF and written about them. Available at: www.roseindia.net/jsf I believe that I am right in my reservations about JSF.
  230. Re: about JSF[ Go to top ]

    "Are you somehow confusing Struts with JSF? I'm getting so tired of people bashing JSF who apparently know absolutely nothing about it."
    No. I am not confusing Struts and JSF. I am comparing asp.net webforms with JSF.
    I have worked in Struts, ASP.net(c#) and JSF and written about them.
    Available at:
    www.roseindia.net/jsf
    I believe that I am right in my reservations about JSF.
    You are wrong. You don't need a class for each form in JSF. You can have one class for many forms, or many classes for one form. For example, in one web page you can have value and method bindings for any number of different backing beans.
  231. Re: about JSF[ Go to top ]

    "Are you somehow confusing Struts with JSF? I'm getting so tired of people bashing JSF who apparently know absolutely nothing about it."
    No. I am not confusing Struts and JSF. I am comparing asp.net webforms with JSF.
    I have worked in Struts, ASP.net(c#) and JSF and written about them.
    Available at:
    www.roseindia.net/jsf
    I believe that I am right in my reservations about JSF.
    I don't believe you have worked with JSF to say things like that. You are really confusing it with Struts. JSF has strong data bindings facilities (something Struts has always lacked) that you can use to bind your UI components to about any objets you want (usually backing beans properties).
  232. ASP.NET vs JSF[ Go to top ]

    "I don't believe you have worked with JSF to say things like that. You are really confusing it with Struts." --------------------------- We are NOT comparing Struts and JSF in this discussion but ASP.net and JSF. Connecting a asp:datagrid to a datareader or dataset is extremely simple. Unless, we have worked in both JSF and ASP.NET webforms, we cannot arrive at objective assessment. I presume that you have worked in asp.net? Please try , if you already have n't. Dotnet Framework SDK is enough. And plead with the Java community to make JSF as simple. You can read my simple primer to asp.net at: http://in.geocities.com/rsramsam/aspdotnet1.htm Bye.
  233. "We are NOT comparing Struts and JSF in this discussion but ASP.net and JSF" No we are dicussing totalitarism vs "the opposite" Arstechnica May 31, 2006 @ 1:56AM: SQL Server's market share continues to grow; MySQL could spark big changes. http://arstechnica.com/journals/microsoft.ars/2006/5/31/4163 God news for all that believe in freedom & democracy. Best regards Rolf Tollerud
  234. Re: ASP.NET vs JSF[ Go to top ]

    "I don't believe you have worked with JSF to say things like that. You are really confusing it with Struts."


    ---------------------------
    We are NOT comparing Struts and JSF in this discussion but ASP.net and JSF. Connecting a asp:datagrid to a datareader or dataset is extremely simple. Unless, we have worked in both JSF and ASP.NET webforms, we cannot arrive at objective assessment. I presume that you have worked in asp.net? Please try , if you already have n't. Dotnet Framework SDK is enough. And plead with the Java community to make JSF as simple.
    You can read my simple primer to asp.net at:
    http://in.geocities.com/rsramsam/aspdotnet1.htm

    Bye.
    Here what you said :
    All the points mentioned by you on j2ee products , are correct. You had carefully mentioned that your organization deals only with Intranet environment and does not have scalability problems. But if you want Enterprise container services , then EJB-3 is the way to go. In web-tier, ASP.net is very elegant and easy to learn and use. JSF is a horror. Imagine, creating a class for each form. No such trouble in ASP.net.
    If you have actually used JSF, you'll see that your statement is totally untrue. You can link your components directly to your business objects. Once again, as 2 posters other than me already told you, this is the STRUTS way and not the JSF's. So don't try to compare JSF to ASP.net when clearly you have never tried it.
  235. Re: ASP.NET vs JSF[ Go to top ]

    All the points mentioned by you on j2ee products , are correct. You had carefully mentioned that your organization deals only with Intranet environment and does not have scalability problems. But if you want Enterprise container services , then EJB-3 is the way to go.
    In web-tier, ASP.net is very elegant and easy to learn and use. JSF is a horror. Imagine, creating a class for each form. No such trouble in ASP.net.


    If you have actually used JSF, you'll see that your statement is totally untrue. You can link your components directly to your business objects.

    Once again, as 2 posters other than me already told you, this is the STRUTS way and not the JSF's. So don't try to compare JSF to ASP.net when clearly you have never tried it. "creating a class for each form" is not only the Struts way, it is also the ASP.NET way (unless you don't use code-behind, thus making you code like model 1 JSP). It is not bad at all.
  236. Code behind in asp.net[ Go to top ]

    "creating a class for each form" is not only the Struts way, it is also the ASP.NET way (unless you don't use code-behind, thus making you code like model 1 JSP). It is not bad at all. " ----------------------------------------------------- True. But, asp.net does not force us to compile the codebehind file. We can just separate the script section and the gui section. It is very easy and elegant. We can also compile and refer to that, just as we do in JSP using bean. But the options are there. No xml file to mess around. All that I am saying is that JSF should be made as simple as ASP.net webform. Is not the asp:datagrid example revealing?Could it get any simpler? Is it this easy in JSF? I have given links to my lessons on both JSF( 3 parts) and ASP.net. Any errors in that?
  237. Re: Code behind in asp.net[ Go to top ]

    "creating a class for each form" is not only the Struts way, it is also the ASP.NET way (unless you don't use code-behind, thus making you code like model 1 JSP). It is not bad at all. "
    -----------------------------------------------------
    True. But, asp.net does not force us to compile the codebehind file. We can just separate the script section and the gui section. It is very easy and elegant. We can also compile and refer to that, just as we do in JSP using bean. But the options are there. No xml file to mess around.
    All that I am saying is that JSF should be made as simple as ASP.net webform.
    Is not the asp:datagrid example revealing?Could it get any simpler? Is it this easy in JSF?
    I have given links to my lessons on both JSF( 3 parts) and ASP.net. Any errors in that?
    Sorry, no time to review your training materials.
  238. Re: Code behind in asp.net[ Go to top ]

    Your problem, sir, is that your original post stated: "JSF is a horror. Imagine, creating a class for each form." Anyone who has any experience with JSF knows that you can have one form with multiple classes, or one class with multiple forms. So, by making this statement, you completely lost any credibility. You should be more careful about making sure you have your facts straight before making statements about a technology being "a horror". At this point, I'm afraid you'll have to leave it to others to make credible arguments as to the virtues of ASP.NET over JSF.
  239. summing up.[ Go to top ]

    This discussion is already very long and the main posters, , have placed their arguments along 'predictable' lines.(J2EE,RUBY, MICROSOFT...camps).Dino Chisea is an exception & I suspect that he is really a Java admirer at heart...just continuing in Microsoft tradition of a soft corner for Java!Those who are familiar with J++, will know that Microsoft's COM can be easily created by just compiling a javabean using MS Java compiler. Is not C# ,a left-handed complement to Java? He represented Microsoft at JavaOne(2005) and spoke about his desire to educate the Windows developers on Java (or something to that effect.I am not quoting). Kudos to him for presenting a balanced comparison of C# and Java & J2EE and DotNet.All the same, Java is stiil the better choice , for its platform independence. It was also admitted in that session that Microsoft has no technology equivalent to the EJB (I suppose , Entity beans were meant..because MTS was the forerunner of EJB session beans). Also about the absence of any ORM approach in Microsoft camp. They were talking about XML -WebService Inter-op. Since then, the co-operation between Sun and Microsoft has only become More and not Less. This is a tacit admission that no version of Unix/Linux is going to replace Windows at the desktop in the near future. Equally important admission that the server side is dominated by Unix/Linux, except in company Intranets.It does not mean that Microsoft will not try to use Unix in Windows under a different name (as Mac-10 is doing with success) and try to become another Unix company,in near future. Why not? They already had XENIX but gave it up, for some reason.. I think this runs counter to the perception of Rolf Tollerud ( BTW, P.G.Wodehouse..not Woodhouse..we all love Wodehouse for his 'chaste' & brilliant English,wit and humour) who thinks that Microsoft is trying to minimise the importance of Server side.One hears so much about SOA these days and it is all about server side and XML Webservice.. May be, just as Java is a nice language for all types of applications like desktop,client-server,web-server, enterprise-server and also mobile applications( and James Gosling is hinting at Real Time Java too), Microsoft is trying to create a platform which combines the best features of Mac with server-side platform like Unix.I think some people are stuck up in the cold-war days of Microsoft Vs Sun litigation. Those days are over. Java's chief merit then ,now and for the future ( especially in the emerging field of wireless and mobile clients) is its WORA philosophy.It is a compiled language unlike the Scripting languages and Enterprise applications require raw speed. Granted, for speed C++ is the best choice but it lacks portability. All this is good-old stuff repeated ad-nauseum during the decade from 1996 to 2005. As has been pointed out correctly, many of the LEGACY Enterprise class applications are in C++ and COBOL.That requires EAI and J2EE is precisely an attempt to address this CORBA-LIKE problem within Java itself to the extent possible. We should differentiate between Enterprise data & appplications 'already in existence' and the newly created applications.Any new Enterprise class applications are better built using Java/j2ee and the same can be used to integrate with legacy too. Why should we learn a different language for each tier?unless Java is inadequate, which is yet to be proved by any of the scripting language competitors? There is already a bewildering complexity and variety. Why add more? Java succeeded primarily for that reason and it reamins valid today. WORA is always better than WriteOnce -Run Natively.Advances in hardware technology will see to it that Java code is sufficiently fast. ------------------------------------ Java/J2ee solutions can be free too, unlike ASP.net in Windows. DotNet is using the COM+ of old days..And the Mono version has no such counterpart. Anti-EJB people are citing Rod Johnson often.Rod Johnson has not criticised Stateless beans and Message-driven beans. Many of the J2EE technologies are approved by him.Most of the perceived weakpoints have been set right in EJB-3. However, many in the Java camp ,all celebreties, are not happy with Annotations.Nor with XML files. It will be a great breakthrough if some solution based on a Java-related version of Scripting language can obviate annotations and too much xml files. ASP.net is very good in this also. It hides much of this XML , from the programmer. Scripting languages are welcome not by themselves but as glue within Java programs. Ever since 1996, there has been a leap-frogging race between Sun and Microsoft. At each stage, Sun(Java) was a winner, till the arrival of ASP.net's webforms! Java language and the applet technology were better than downloading ActiveX controls into the registry(security?). Servlets were better than ASP based on VBScript. Then JSP using bean was better than ASP with COM objects. Then came Struts without being JCP standard.The elegance was lost. Bill Joy is said to have remarked in the early days of Java, that if something cannot be done in a simple and elegant manner, it is better not to bring it in.Elegance is reflected in the class names too. JSWDP from SUN used to compile and develop Servlets and JSP was a zip of mere 750 k and expanded folder was about 3 mb. It was fast. Then came Tomcat3.2 ,reasonably fast. Today, Tomcat5 is about 50mb. What is being attempted by both ASP.net and JSF is to create a program much like an applet but in the server-side.When we look at the code for an ASP.net program, we feel that we are looking at an applet event-handler except that the GUI code has been taken care of by the asp.net special tags. The code is so much closer to JDK. If someone were to say that ASP.net written in j# , is from the Java community as a successor to JSP , new entrants will be absolutely convinced.That is how, JSF should have been implemented. The tag names in Asp.net are intuitive. Asp.net tag names like checkboxlist, radiobuttonlist,listbox etc are closer to JDK than those of JSF. How is it that tag names in JSF are so outlandish?inputsecret?why not password?outputlabel?Is there an inputlabel?why not just plain label?And 'backing beans'...more likely to be read as 'baking bean'! Could they not show some style? Do all asp.net pages depend on backing beans? Afterall, the JSF team had the ASP.net example before their eyes for nearly 4 years! Why not adopt the same style? How is it that Microsoft has done such a neat and wonderful job in creating 'server-side-created applet'? Why 'clutching at a straw'( not 'catching a straw') for a supposed bloomer? How is it that ASP.net page can be functional without any pre-existing user defined class? just as self-contained as an applet is, if need be?The question is not whether each form can be linked with one class or many. Normally, Open-source and standards committee are meant to pool the talents of great many experts. Quality-wise ,it should then be better than a closed-source endeavour.But ASP.net has done a better job, more intuitive to a Java programmer.Now, JSF has become a standard and tools will be based on that.More and more difficult to go back.Is it not better to remember that not all programmers are API developers ? Actually, most are Application developers. Microsoft has always shown better awareness of the needs of such programmers. Even today, JDK also is like that. First the XML files and then too much administrative things have marred it. In IDE environment, the above demerit will not make much difference. But, the joy of JDK ( and DotNetFramework SDK) programming , using just a text editor and command line is lost.ASP.net is fine even without Studio. Many JSF developers also would work with text-editor and command line. Since when has the Unix enterprise world become an addict to studio type of programming? What is so great about a software be it Eclipse or Netbeans or Oracle10g which requires atleast 512 MB to work reasonably well? Ajax has to be used since neither JSF nor ASP.net can be fast enough for user-interaction.James Gosling has spoken about undesirable practice of bringing in Javascript.He fears security problems. And browser incompatibility problems. Would not a fast-loading applet be a solution now, instead of all these contorted techiques?Is it not possible for the Java experts to come out with a solution? They can, if they try. Before I forget...a very important request. The Struts application comes with struts-blank.war and it is renamed to our application name . It would have been better if the JSF distribution also came with such a skeleton application. But , there is no such demo in the JSF distribution. May I request for this feature through this august forum? ---------------------------------------------------------
  240. Re: summing up.[ Go to top ]

    Remember JSF implementations can render to technologies such as VT-100 text terminals, but ASP.NET can't :-)
  241. Re: summing up.[ Go to top ]

    Remember JSF implementations can render to technologies such as VT-100 text terminals, but ASP.NET can't :-)
    This may not be that useful, but it demonstrates the versatility of JSF. What is potentially very useful is to be able to re-use much of the same code (and the same development tools and skills) to produce HTML, HTML + AJAX, WML, SVG, XUL and others.
  242. Re: summing up.[ Go to top ]

    Remember JSF implementations can render to technologies such as VT-100 text terminals, but ASP.NET can't :-)
    This may not be that useful, but it demonstrates the versatility of JSF. What is potentially very useful is to be able to re-use much of the same code (and the same development tools and skills) to produce HTML, HTML + AJAX, WML, SVG, XUL and others.
  243. Re: ASP.NET vs JSF[ Go to top ]

    All the points mentioned by you on j2ee products , are correct. You had carefully mentioned that your organization deals only with Intranet environment and does not have scalability problems. But if you want Enterprise container services , then EJB-3 is the way to go.
    In web-tier, ASP.net is very elegant and easy to learn and use. JSF is a horror. Imagine, creating a class for each form. No such trouble in ASP.net.


    If you have actually used JSF, you'll see that your statement is totally untrue. You can link your components directly to your business objects.

    Once again, as 2 posters other than me already told you, this is the STRUTS way and not the JSF's. So don't try to compare JSF to ASP.net when clearly you have never tried it.
    "creating a class for each form" is not only the Struts way, it is also the ASP.NET way (unless you don't use code-behind, thus making you code look like model 1 JSP). That is why ASP.NET aspx pages are called Web forms. It is not bad at all.
  244. Re: ASP.NET vs JSF[ Go to top ]

    "I don't believe you have worked with JSF to say things like that. You are really confusing it with Struts."


    ---------------------------
    We are NOT comparing Struts and JSF in this discussion but ASP.net and JSF. Connecting a asp:datagrid to a datareader or dataset is extremely simple. Unless, we have worked in both JSF and ASP.NET webforms, we cannot arrive at objective assessment. I presume that you have worked in asp.net? Please try , if you already have n't. Dotnet Framework SDK is enough. And plead with the Java community to make JSF as simple.
    You can read my simple primer to asp.net at:
    http://in.geocities.com/rsramsam/aspdotnet1.htm

    Other factors aside, C# delegate/event definitely gives ASPNET an edge over JSF.
  245. People[ Go to top ]

    .NET and its simplicity (a lot are saying lack of options) are good. They are great when you know exactly what you're doing. And that's where the problem starts. Most of .NET developers come from a VB background. And most of vbers are failed computer science undergraduates or folks from different fields (marketing, administration, etc.) that figured out how to easily create forms that populate "automatically, can you believe?" .mdb and .xls files. These folks don't need and don't want to know what's going on behind the curtains; they simply don't care. They can't produce high quality software. They don't even know that it's possible at all. They are proud of themselves and when faced with such components as operational systems or DMBS (which are not the most advanced piece of software existent today, by far) they think "How come?" or simply "that's not for us mere mortals". And still, a lot of corporations have this kind of "computer field professional". A lot of times, they say among them "I can't find a component to do this feature. Let's wait until Microsoft releases a new control at the next release of VB/.NET (XX) platform. Let's tell the customer what he wants can't be done". For the sake of simplicity, I won't elaborate on the psychological impacts of this kind of behavior in the minds of the corporate world (the customers) today - I think it’s obvious. Microsoft likes it; if people can't and don't know how to create stuff by themselves, they are tied to them. If that's really their strategy, then they are right; they are not a charity organization. I don't think it's by chance that MS likes to invent their own computer science and do not like to reinforce certain practices in their "computer field professionals oriented" products. It's strategy. As someone pointed earlier "from a technical standpoint, they could do it. They chose not to". On the other corner, there are Java and C++ developers. From the beginning, Java developers are bombarded with a lot of concepts (Abstractions - that one is funny, Frameworks, OO, S.O.C., Unit Testing, Design Patterns, Object Relational Mappers, etc.) that, and I think you all agree on that, are core concepts when it comes to producing High Quality Software today. They communicate through these concepts. They create their own concepts using those before mentioned as building blocks. They are truly enabled for producing higher quality software. They can understand what's going on behind the curtain, because they care to and know that can bring value to their customers. Note, I'm not saying .NET is better or Java is better. I'm talking about how most of the developers arrive at one place or the other. These are empirical observations, results from some years developing and managing teams of developers. As a development team leader, if a project is suited for .NET (I'll abstract the possible reasons for such a scenario), I'll go for it. But i will darn be sure that I've chosen the right people. And surely, if they have some java background, their chances are higher - at least today.
  246. what's it all about[ Go to top ]

    ..most of vbers are failed computer science undergraduates or folks from different fields (marketing, administration, etc.) that figured out how to easily create forms that populate "automatically, can you believe?" .mdb and .xls files. These folks don't need and don't want to know what's going on behind the curtains; they simply don't care. They can't produce high quality software
    But you see Andre, that is where you are wrong. Before I go further I will clarify this "war", what it is all about, or between. Just to compare in a completely unrelated subject what is "war against terrorism"? Is it a war between civilisations? No. Is it a war against Muslims? No. Against Arabs. No. What then? It is about whether priests shall rule or democracy. In a similar way "Java or .NET" is not really about Java or .NET. It is centralization against "let 1000 flowers bloom". Sun, IBM and Oracle advocates and offer complete key-ready solutions where all runs from server and the users are discouraged (sometimes even clubbed down :) from doing anything. All is very expensive but works only so-and-so. Microsoft on the other hand says, "You don't need any of this, you can do your systems yourself" So much more with users of today that are more technology savvy, generally educated and knowing about their business than before and include new groups with far reaching access into the companies. So what about Open Source? They are on the side of Sun-IBM-Oracle. According to IBM the typical project consulting costs are 11 times the cost of the software, so with the software free is still doesn't count for .The solutions still cost 10-20 more than necessary. Actually that is the real reason for IBM to pour billions of dollars into Linux and other OSS tools. I am siding with Microsoft. The IBM way is so Nineties IMO. Many says, "please, it is not about religion!" But that is exactly what it is. Regards Rolf Tollerud
  247. People[ Go to top ]

    Rolf, What you're saying is a summary of Microsoft's current Marketing Campaign. As a digression, let me ask you, it's funny, do you work in their strategic marketing organization? Anyway, you somehow missed the point here. It's great to have empowered users doing lots of basic and sometimes even medium complexity solutions. But that's it. They are end users. They didn't expend years of their life understanding complex concepts that allow you to come up with a complex Risk Analysis system or a CRM system working 24 x 7, with 10.000 simultaneous users spread geographically throughout the world. And that's what I'm talking about. There's a lot of solutions like this out there, being handled through this "power user" mindset and producing catastrophic failures, contributing to the poor vision a lot of companies have on software. I don't recall exactly, but once someone said: every complex problem has at least a simple solution. That doesn't work. This simple solution is likely to bring new problems, that in short time will cost you twice the price to come with the right solution in the first time.
  248. central steering don't work[ Go to top ]

    Andra, It should be obvious by everyone that I am not a "professional programmer". I humbly belong to the so called "empowered users" that you talk about. But just to get the things right so you do not think I am dragging along a small inferiority complex, I do have to mention that I consider myself not stupid, speak 4-5 languages, have a solid classical education, reads a lot, compose directly for the score without help of a piano, etc. I also have worked full time for more than 15 year as computer consultant and made a lot of money, millions even.. So I don't think I need to make excuses for myself. Still if I meet somebody like Rod Johnson, Juergen Hoeller, Vic Cekvenich, Peter Lin or the like I speak only when spoken to, and fecth coffee. But the problem is that in this centralized ""theserverside" places you never meet people like this. Only 90% incompetents that never should got a job anywhere if I had anything to say about it. If you know something about & life you should know that this is always the case with centralized work areas. not only in computer field. Perhaps you have been in the military? Then you know what I mean. "CRM system working 24 x 7, with 10.000 simultaneous users spread geographically throughout the world" On the point of a gun should never be allowed to computer consultants. Buy finished product. Regards Rolf Tollerud
  249. Re: central steering don't work[ Go to top ]

    Andra, It should be obvious by everyone that I am not a "professional programmer". I humbly belong to the so called "empowered users" that you talk about. But just to get the things right so you do not think I am dragging along a small inferiority complex, I do have to mention that I consider myself not stupid, speak 4-5 languages, have a solid classical education, reads a lot, compose directly for the score without help of a piano, etc. I also have worked full time for more than 15 year as computer consultant and made a lot of money, millions even.. So I don't think I need to make excuses for myself. Still if I meet somebody like Rod Johnson, Juergen Hoeller, Vic Cekvenich, Peter Lin or the like I speak only when spoken to, and fecth coffee. But the problem is that in this centralized ""theserverside" places you never meet people like this. Only 90% incompetents that never should got a job anywhere if I had anything to say about it. If you know something about & life you should know that this is always the case with centralized work areas. not only in computer field. Perhaps you have been in the military? Then you know what I mean. "CRM system working 24 x 7, with 10.000 simultaneous users spread geographically throughout the world" On the point of a gun should never be allowed to computer consultants. Buy finished product. Regards
    Rolf Tollerud
    Man you're too funny. I don't remember ever asking you to get coffee. But since you're offering, I'll take a late. I have joked with cameron in the past and asked when tangosol's going to release a dunkin donut version of coherence. If I had the power to change C# and Java, there's quite a few things I'd change. Sometimes I curse Sun for stupid things in Java, but honestly I doubt I could have done as good of job as Sun or Microsoft building an entire platform. Heck, just about every group including apache has stupid things. I fail to see how central steering doesn't work on the whole. Sometimes they work and sometimes they fall flat on their face. peter
  250. Re: central steering don't work[ Go to top ]

    Don't let the fact that you were mentioned together with those prominent persons go to your head! :)
  251. Re: central steering don't work[ Go to top ]

    Don't let the fact that you were mentioned together with those prominent persons go to your head! :)
    Who are those people? I thought they were notorious. I make far too many mistakes every day to think I know anything. Maybe in another 15 years I'll know something. peter
  252. Re: People[ Go to top ]

    The company department I work for has been called "power-user system hospital" already, as every month pops up a new "system" devised by a power user, made with MS-Access, ASP or similar technologies, which start just fine, but once they reach a certain size and complexity, these power-users come running to us asking for fixes and help. We have a hard time making it all work again, by using a real database, creating database relationships and constraints, migrating original data (in bad shape, of course) to the new database, fixing bad ASP code and all. The problem is that power-users think it takes too long for IT dept to create a system the right way, and they're partially right. IMO we should fix the process where IT could solve users problems faster, instead of having users grab some tools with which they'll pretend they are developers, it simply doesn't work because eventually down the road their systems will hit a complexity level where development knowledge is demanded beyond whatever best power-user may ever have (else such power user could be seen being in the wrong place, and should belong to IT dept in the first place!). This kind of power-user systems are very bad for the company as a whole, since these apps probly won't have any notion of integration, security, database normalization and constraints, etc. Usually these power-user systems solve a specific problem quickly, but in the long run they usually run out of control and become monsters, and that's when we come to the rescue. There's actually some benefits in having some power-users but that should be very limited, both in time and scope, as to avoid the hazards of these systems growing over their initial intended solution.
  253. Usually these power-user systems solve a specific problem quickly, but in the long run they usually run out of control and become monsters, and that's when we come to the rescue
    When the system grows to much or for any other reason the author need help he usually hires an outside consultant (like me! :). Why should he be satisfied with a sourly fellow (that is taken away from his so called "real" work) that know even less of the tools in question than the user and have an overbearing and bad attitude when he can became a customer, somebody that is defered onto? Regards Rolf Tollerud
  254. Usually these power-user systems solve a specific problem quickly, but in the long run they usually run out of control and become monsters, and that's when we come to the rescue


    When the system grows to much or for any other reason the author need help he usually hires an outside consultant (like me! :). Why should he be satisfied with a sourly fellow (that is taken away from his so called "real" work) that know even less of the tools in question than the user and have an overbearing and bad attitude when he can became a customer, somebody that is defered onto?

    Regards
    Rolf Tollerud
    Hum... fetching coffes may solve one power user problem, but not the company's.
  255. Re: People[ Go to top ]

    This kind of power-user systems are very bad for the company as a whole, since these apps probly won't have any notion of integration, security, database normalization and constraints, etc. Usually these power-user systems solve a specific problem quickly, but in the long run they usually run out of control and become monsters, and that's when we come to the rescue. There's actually some benefits in having some power-users but that should be very limited, both in time and scope, as to avoid the hazards of these systems growing over their initial intended solution.
    That sounds familiar. Oh yeah, it was the same thing that the priests of the hardware were saying about programmers back in the 50s.
  256. Re: People[ Go to top ]

    This kind of power-user systems are very bad for the company as a whole, since these apps probly won't have any notion of integration, security, database normalization and constraints, etc. Usually these power-user systems solve a specific problem quickly, but in the long run they usually run out of control and become monsters, and that's when we come to the rescue.
    There's actually some benefits in having some power-users but that should be very limited, both in time and scope, as to avoid the hazards of these systems growing over their initial intended solution.


    That sounds familiar. Oh yeah, it was the same thing that the priests of the hardware were saying about programmers back in the 50s.
    And your point is?
  257. Re: People[ Go to top ]

    That sounds familiar. Oh yeah, it was the same thing that the priests of the hardware were saying about programmers back in the 50s. And your point is?
    To an assembly language programmer, a Java programmer is just a power user. C programmers probably feel the same way. Hell, the functional language programmers probably feel the same way too.
  258. Re: People[ Go to top ]

    That sounds familiar. Oh yeah, it was the same thing that the priests of the hardware were saying about programmers back in the 50s.


    And your point is?



    To an assembly language programmer, a Java programmer is just a power user. C programmers probably feel the same way. Hell, the functional language programmers probably feel the same way too.
    I was a C programmer for a long time, and was relieved to find Java. No more mallocs, pointer arithmetics, core dumps and all the hell that came with that. At least in my experience, C programmers don't feel like that a bit. And I don't know one assembly programmer who's ever made any enterprise development, so I can't say anything about them, if they exist.
  259. Re: People[ Go to top ]

    I was a C programmer for a long time, and was relieved to find Java. No more mallocs, pointer arithmetics, core dumps and all the hell that came with that. At least in my experience, C programmers don't feel like that a bit. And I don't know one assembly programmer who's ever made any enterprise development, so I can't say anything about them, if they exist.
    That's nice that you like Java and assembly language programmers don't produce anything enterprisey, but that doesn't address the issue about knowing what's going on under the hood, or some arbitrary classification of "power users".
  260. Re: People[ Go to top ]

    I was a C programmer for a long time, and was relieved to find Java. No more mallocs, pointer arithmetics, core dumps and all the hell that came with that. At least in my experience, C programmers don't feel like that a bit. And I don't know one assembly programmer who's ever made any enterprise development, so I can't say anything about them, if they exist.


    That's nice that you like Java and assembly language programmers don't produce anything enterprisey, but that doesn't address the issue about knowing what's going on under the hood, or some arbitrary classification of "power users".
    If you read my posts above, you'll see clearly what's my definition of power-user, which IMO fits with the general idea of power-user, so it's not something I have just coined now. Anyway, stating that Java developers could be classified as power users is a long stretch by any measure, no matter how many lines of assembly one has (or has not) written all his life. Actually, that's even a contradiction, since people have complained about Java complexity (and that's the origin of this very thread) and lack of toolability or ease of use, which bars "power users" (in the common definition of the term) in the first place.
  261. Re: People[ Go to top ]

    They didn't expend years of their life understanding complex concepts that allow you to come up with a complex Risk Analysis system or a CRM system working 24 x 7, with 10.000 simultaneous users spread geographically throughout the world. And that's what I'm talking about. There's a lot of solutions like this out there, being handled through this "power user" mindset and producing catastrophic failures, contributing to the poor vision a lot of companies have on software.
    Correct me if i'm wrong, but you can hardly imagine such power users even trying to make your complex, 24 x 7, 10.000 simultaneous users application and succeeding. But imagine they did try and indeed fail miserably. I can not imagine any company willing to have them in there development department. And if they have, I can not imagine such a company surviving. That is, if the applications they develop are really so terrible as you state. So, either this is a non-issue, as such people will get "eliminated" from the business through "survival of the fitest". Or your inference is wrong, and it is possible to develop those complex systems VB-style. Personaly, I can hardly imagine your power users being hired by a company producing such complex systems. Imagine: "Hello, we're a company developing web applications accessible from all over the world by 10.000 users, with servers geographically spread needing to be synchronized through replication, and are looking for a developer", and then the applicant answers: "Hi, i'm a power user and developed an MS-Access application using some wizards and the only CRUD i know are the crudities in my soup.", and the company answers "Great, when can you start?". I would like to now why you think most .Net developers have a VB background? Why is it not possible that they come from a C++ background? And why do you think that someone with a C++ background automatically produces good code? I've experienced the opposite. I started myself as a power user, but was lucky to get my passion for software across to my current employer, so now i'm using C++ and .Net. I do not think bad coding is about using .Net or Java or any other language, I think it is about having a passion for your work. Surely, some languages will be easier to write ugly code, but a power user can write ugly code using any language. And I admit VB is probably the preferred language for power users, but i think that's a good thing. It proves that it kept it's promise: give your everyday user a tool to get something more from his application.
  262. Re: People[ Go to top ]

    Personaly, I can hardly imagine your power users being hired by a company producing such complex systems. Imagine: "Hello, we're a company developing web applications accessible from all over the world by 10.000 users, with servers geographically spread needing to be synchronized through replication, and are looking for a developer", and then the applicant answers: "Hi, i'm a power user and developed an MS-Access application using some wizards and the only CRUD i know are the crudities in my soup.", and the company answers "Great, when can you start?".
    No one hires a power-user to seat at a developer's chair. Usually they are experienced employees who know the business and happen to know some tools like ASP and Access or the like, so they're able to create small/mid sized departamental systems (but with all the problems I mentioned before). This happens a lot in the company I work for, which until recently didn't have any policy regarding exclusive IT dept "rights" to create and maintain systems. Being it a big company with thousands of employees scattered throughout the country in tens of offices, one can imagine the probability such departamental "solutions" created by power-users may pop up. I imagine this must happen a lot in every big company where strict software deployment/development/maintenance is not enforced. Now imagine what would happen if every power-user in a big company is given freedom to start creating any and all small/mid size system to solve their local problems (which aren't *that* local to begin with if one analises it correctly). Imagine the caos it would be when high management asks IT dept for a report which would require that information scatered in these hundreads of small dept systems be summarized? I am sure Rolf has an answer. It just isn't cheap or fast... Got it now why he defends these tools like it were his only possible source of income? ;)
  263. VB6? Access? Windows 98? What dream world are you living in? That was many years ago. The typical products Microsoft powerusers/consultants use today are Server 2003/or Small Business Server, Exchange with Active Directory, SQL Server, Microsoft CRM, Office with Sharepoint. Typical run-of-the-mill setup in a small or middle size company today, glued together with .NET. The same story, over and over again. Regards Rolf Tollerud
  264. Re: People[ Go to top ]

    This happens a lot in the company I work for, which until recently didn't have any policy regarding exclusive IT dept "rights" to create and maintain systems. Being it a big company with thousands of employees scattered throughout the country in tens of offices, one can imagine the probability such departamental "solutions" created by power-users may pop up. I imagine this must happen a lot in every big company where strict software deployment/development/maintenance is not enforced.Now imagine what would happen if every power-user in a big company is given freedom to start creating any and all small/mid size system to solve their local problems (which aren't *that* local to begin with if one analises it correctly). Imagine the caos it would be when high management asks IT dept for a report which would require that information scatered in these hundreads of small dept systems be summarized?
    So, if i use (for example) MySQL as a database, then automagically (error intended, the others aren't ;-)) i will not have these problems? I will suddenly create database with the perfect balance between normalization and denormalization and because i use Java, automagically i will have a perfectly structured program. And my collegue power user in the other department will automagically have chosen MySQL as well and will have created a database for his problem that is perfectly compatible with mine so that guy in management can have his report? Don't get me wrong, I agree with your problem statement. I don't agree with your cause analysis. And alltough i will admit that ms-access and the like have made it somewhat easier for such things to happen, i don't believe banning them will stop the problem. If your company doesn't have a policy regarding inhouse development, then there will always be some "power user" with a hobby interest in programming who will download some tools (be it java, .net or any other language or database) and start a project himself. It's people who use the tools, and it's people who use them right or wrong. And as long as there are people who prefer instant gratification over a carefully thought of piece of software, there will be people who prefer writing a quick and dirty program doing what they want it to do. The java community has produced some wonderfull projects ( i even got to know some new ones reading the comments of this post), but i bet anyone can use them to produce a piece of software that is a nightmare to maintain. If you want to eliminate this problem, you will have to change a mentality, and saying the tools are the cause will not get you any further because that way you are giving people the perfect excuse not to change anything because: "Hey, it's not my fault, it's the tools !!!"
  265. Re: People[ Go to top ]

    Of course I am not blaming the tools, any more than I should blame the gun for the murder! ;) But you must agree that if there were less guns out there, murder rates would go down. And easy of use plays a role here too, else less people would be able to create these kinds of systems. And I agree that bad code can and will exist whatever language/tool/platform is used. Each is a different part of the problem, actually. As I said before, IMO the solution (at least in my case at the company I work for) is to have a strong IT dept, technically able to deliver solutions faster, plus a company policy of no system development outside IT dept, or without its consent at least. Denying the use of development tools should help avoid this problem too (but not completely, since some people would end up working on these local dept systems even at home!). So Rolf, it doesn't matter if it is Java, VB, Access, Delphi, or the shiny microsoft silver-bullet-of-the-year. The problem lies in the power-user mentality. They simply don't realise they're actually hurting the company, wasting and duplicating their efforts, since the same solution is created again and again in different places, as they are solving locally a common, recurring company-wide problem, and each place will come with a different solution, where a enterprise system should solve for the whole company at once. I don't blame them, they're just trying to solve their problems, filling a hole which exist because of lack of a stronger IT dept. But giving them more power would just make matters worse. I am talking about a 6000 employees company here, not a small factory at the corner. Have the power-user hire a consultant to help him won't make it too, because the consultant will still solve the power-user problem following his local view of the issues, not the whole company's.
  266. Re: People[ Go to top ]

    Of course I am not blaming the tools, any more than I should blame the gun for the murder! ;) But you must agree that if there were less guns out there, murder rates would go down.
    Right you are. But people invented cars to be able to travel long distances in shorter time. Only some people use it to drive from their doorstep to their mailbox to get their mail (yes, some people still write letters) and then grow fat. What are you gonna do, blame car manufacturers for fat people and ban all cars?
    They simply don't realise they're actually hurting the company, wasting and duplicating their efforts, since the same solution is created again and again in different places, as they are solving locally a common, recurring company-wide problem, and each place will come with a different solution, where a enterprise system should solve for the whole company at once. I don't blame them, they're just trying to solve their problems, filling a hole which exist because of lack of a stronger IT dept.
    Great, so if you have a big company spread all over the world with lots of people, then you should have a strong IT department. Because, like you say, there will be reoccuring problems that can be solved by this single strong IT department. But of course, there are other companies which face similar problems like yours and maybe you will have to integrate your data with theres. So why not make a single inter-company IT-department that can solve all these common problems. Mmmm, sounds familiar... I guess deep down inside of you there is a Microsofty trying to get out after all. You should call Bill and propose working for their marketing department.
    So Rolf, it doesn't matter if it is Java, VB, Access, Delphi, or the shiny microsoft silver-bullet-of-the-year.
    Where not all working for world-wide, Fortune 500 companies, some of us are even working for rather small companies, like 20 to 50 people. And they will be happy with that VB, Access, whatever low-level entry solution that solves their problem.
  267. Re: People[ Go to top ]

    Of course I am not blaming the tools, any more than I should blame the gun for the murder! ;) But you must agree that if there were less guns out there, murder rates would go down.

    Right you are. But people invented cars to be able to travel long distances in shorter time. Only some people use it to drive from their doorstep to their mailbox to get their mail (yes, some people still write letters) and then grow fat. What are you gonna do, blame car manufacturers for fat people and ban all cars?



    They simply don't realise they're actually hurting the company, wasting and duplicating their efforts, since the same solution is created again and again in different places, as they are solving locally a common, recurring company-wide problem, and each place will come with a different solution, where a enterprise system should solve for the whole company at once. I don't blame them, they're just trying to solve their problems, filling a hole which exist because of lack of a stronger IT dept.

    Great, so if you have a big company spread all over the world with lots of people, then you should have a strong IT department. Because, like you say, there will be reoccuring problems that can be solved by this single strong IT department. But of course, there are other companies which face similar problems like yours and maybe you will have to integrate your data with theres. So why not make a single inter-company IT-department that can solve all these common problems. Mmmm, sounds familiar...
    I guess deep down inside of you there is a Microsofty trying to get out after all. You should call Bill and propose working for their marketing department.


    So Rolf, it doesn't matter if it is Java, VB, Access, Delphi, or the shiny microsoft silver-bullet-of-the-year.

    Where not all working for world-wide, Fortune 500 companies, some of us are even working for rather small companies, like 20 to 50 people. And they will be happy with that VB, Access, whatever low-level entry solution that solves their problem.
    Well, your selective quoting really makes it appear I am disagreeing with you, when I am not. Just to make things clear: 1) no, I don't blame the tools. 2) no, I am not talking about inter-company integration problems, which is a completely different beast. 3) no, I am not talking about small companies, where power users can be a blessing indeed. Is it clear now?
  268. the dream of Eldorado[ Go to top ]

    Henrique,
    So Rolf, it doesn't matter if it is Java, VB, Access, Delphi, or the shiny Microsoft silver-bullet-of-the-year.
    Agree.
    The problem lies in the power-user mentality
    No, IMO the problem is in the central-planning mentality. But at least it is good that we are coming away from this Java .NET discussion because it is not real issue. The Java crowd and and the Open Source Unix people are reminiscences from the same source - the totalitarian age of the big central computers. But central-planning systems have never worked in any kind of human endeavour through the history, with computers or otherwise. I tell you why. 1) It foster bureaucracy. All good for nothing doing nothings are gathering up at those places like old socks at home. 2) In those cases you really have some actual talent it is too dangerous. The power goes to their head, soon hubris leads to The Big Disaster. 3) And whatever you believe, great systems is never done right the first time, neither in computers or elsewhere. Woodhouse for example rewrote his books 7 times. 7 times! A LOL should think that he was a beginner and not one of the all time great authors. Think of the mega mega mega failures last year like the German transport system or the FBI system (or the EJB system, the biggest disaster of all time!) You think that when a poweruser (often very intelligent people like doctors) make a system he waist his time because he has not the necessary bird view. But it is wrong to think in that way, instead you should see it as one of the necessary iterations on the way to a great system And quite likely one of the most best too, far more useful that any at-the desktop-made-wellmeaning-theoretical-specifications. But, the urge to sit alone and construct large systems is stronger than the sex instinct, therefore, this dream to plan everything to perfection will never die. It is like the dream of Eldorado. Regards Rolf Tollerud
  269. Re: the dream of Eldorado[ Go to top ]

    You think that when a poweruser (often very intelligent people like doctors) make a system he waist his time because he has not the necessary bird view. But it is wrong to think in that way, instead you should see it as one of the necessary iterations on the way to a great system

    And quite likely one of the most best too, far more useful that any at-the desktop-made-wellmeaning-theoretical-specifications.
    This is just plain dangerous nonsense. Without the 'bird view', and without the expertise to understand how a system should work (such as knowledge of accounting practices, or legal requirements) the results of power users implementing these things can be worse than not having any IT system at all, as information that would otherwise be retained through well-understood (albeit antiquated) procedures, can be forever lost through entry into an Access database without the appropriate constraints and relational design. Or, just as bad, the same data is entered by different people into different Access-type databases, with different designs. The process of having to extract and reconcile the results of this can be very long and tiresome. Worst of all are the very intelligent power users, who assume that because they have expertise in one area, that designing systems in Access can't be that hard, can it? It is very often far better to wait for a theoretically better system (even if it never arrives), than to let power users design and build their own systems. The answer to too much central-planning mentality (assuming one believes that this is a problem) is not IT anarchy, and you can't possibly have something that is an iteration towards a great system if you don't have any idea (no 'bird view') of what that system has to do.
  270. Rolf, It can't be either one extreme nor the other, I mean, there must be a middle ground where neither hundreads of small incompatible systems exist nor a single huge monolithic system-to-rule-them-all exists. I truly believe that a good development process should be the answer to most of this, one which could deliver the best possible solution to the right group at the right time. Of course the small power-user system is the best solution for him (despite the probable lack of integration, DB constraints, code structure, etc., since development is not his expertise or full-time job, but more of a "hobbye"), so it can indeed be used as a prototype for what a company-wide system must be. In this POV it can be benefitial to the development process, but no more than this. Plus, this notion that a huge system can be created in one shot (waterfall process anyone?) should have been erradicated long time ago, it's crazy people still do it today. Agile methods, spiral or any development process which builds systems in phases should be mandatory, and are a great part of the solution to the discussed situation, IMO. Again, let me make this clear: I am talking about big companies, not small ones. Small ones are completely different situation, where I believe power-users can sometimes be a blessing and not a curse. But the lack of knowledge of proper system development concepts in the long run can be bad, for example if this small company grows, and doesn't switch the power-user system for something more fit for a more complex situation. Regards
  271. Rolf,

    It can't be either one extreme nor the other, I mean, there must be a middle ground where neither hundreads of small incompatible systems exist nor a single huge monolithic system-to-rule-them-all exists. I truly believe that a good development process should be the answer to most of this, one which could deliver the best possible solution to the right group at the right time. Of course the small power-user system is the best solution for him (despite the probable lack of integration, DB constraints, code structure, etc., since development is not his expertise or full-time job, but more of a "hobbye"), so it can indeed be used as a prototype for what a company-wide system must be. In this POV it can be benefitial to the development process, but no more than this. Plus, this notion that a huge system can be created in one shot (waterfall process anyone?) should have been erradicated long time ago, it's crazy people still do it today. Agile methods, spiral or any development process which builds systems in phases should be mandatory, and are a great part of the solution to the discussed situation, IMO.

    Again, let me make this clear: I am talking about big companies, not small ones. Small ones are completely different situation, where I believe power-users can sometimes be a blessing and not a curse. But the lack of knowledge of proper system development concepts in the long run can be bad, for example if this small company grows, and doesn't switch the power-user system for something more fit for a more complex situation.

    Regards
    Often the real problem here is that by the time the IT department, have got the budget approved, done their feasibility study, written the report, rolled out all their, created the requirements spec, heavy weight "Enterprise Strength" tools etc it's too late allready, the business opportunity has passed. So end departments end up hiring Access consultants at £900 per day to knock up what they want when they want it. Can you blame them? After all they are running a business. The answer is really simple, if only we so called IT professionals stoped naval gazing for a moment: Build the simplest thing that can possibly work TODAY In this light things like RoR if used appropriately IMO can really deliver timely business value. Worry about gold plating the solution after you've got something out there working, generating real ROI and gaining real user feedback. Paul.
  272. Re: the dream of Eldorado[ Go to top ]

    In this light things like RoR if used appropriately IMO can really deliver timely business value. Worry about gold plating the solution after you've got something out there working, generating real ROI and gaining real user feedback.

    Paul.
    Yes, but then what? Why not choose light approaches (such as Java+Hibernate+JSF+tomcat) that have the potential to be gold plated later? The danger with adopting many strategies like RoR is that you are closing off this option - reducing future choices. I am not saying go for the full enterprise-ready strategy at the start no matter what. What bothers me is when it is suggested that developers should go for approaches that block off the subsequent option for that strategy. And, I still believe that in many cases the simplest thing than can work today is to sit a developer in front of Studio Creator - it is the simplest thing that can work and it has the potential to be 'enterprise capable'. You don't have to make a choice.
  273. Re: the dream of Eldorado[ Go to top ]

    Hi Steve,
    Yes, but then what? Why not choose light approaches (such as Java+Hibernate+JSF+tomcat) that have the potential to be gold plated later?
    Oh my gosh, we agree. I'm beginning to lean to the view that JSF does fall in the light camp.
    I am not saying go for the full enterprise-ready strategy at the start no matter what. What bothers me is when it is suggested that developers should go for approaches that block off the subsequent option for that strategy.
    We agree on this too. My view is the way to get to the full blown solution is through refactors in response to real world requirements. My view is that pure OO languages like Ruby are conceptually cleaner than Java and intrinsically more productive. Also I believe that these languages are enterprise ready today. Granted, the number of API's and integration libraries available are less than Java, but the answer to this problem is to write what ever you need open source. In time the community will create what ever it needs, rather than being forced to use what ever the vendors choose to sell. Rolf has a point when he points out that real enterprise applications like Billing, Accounts, Payroll, ERP etc have all been written already, mostly in C/C++. What we mistakenly call enterprise applications today are mainly departmental database apps. The reason why relational data is king is because corporations guard their data dearly and choose to mine it using technology like OLAP and Data Warehousing. The applications themselves are secoundary, so why all the ceremony? For every concrete example of where Ruby would not be intrinsically appropriate I could mention at least 10 were it would be (All the apps I've delivered in the last five years could quite easilly have been written in RoR). As for extending the application later, integration technology should ensure that Ruby has access to everything Java has access to. How do we get this integration technology? Well thats an opportunity to make a name for yourself by writing it open source :^). Every programming language has to start some where, after all this was true for Java too. Paul.
  274. Re: the dream of Eldorado[ Go to top ]

    My view is the way to get to the full blown solution is through refactors in response to real world requirements. My view is that pure OO languages like Ruby are conceptually cleaner than Java and intrinsically more productive. Also I believe that these languages are enterprise ready today. Granted, the number of API's and integration libraries available are less than Java, but the answer to this problem is to write what ever you need open source.
    My view is that there are contradictions here. You can't apply the refactoring solution to languages like Ruby that are difficult to refactor (thanks in part to the way that its classes and code are built during execution). Also, the 'write it yourself solution' sounds rather like a Not Invented Here attitute. If there are substantial libraries and APIs present in Java, the sensible approach is... to use Java (or use a language that can use these, like Groovy or JRuby). I don't think there are many developers who truly think that Ruby is enterprise ready today - it is unproven in that role. There are other dynamic languages like PHP that are far more proven. I would agree more with a suggestion that something like Smalltalk is enterprise ready.
    Rolf has a point when he points out that real enterprise applications like Billing, Accounts, Payroll, ERP etc have all been written already, mostly in C/C++.
    The problem is that not all companies or organisations (or whatever size) work in ways that can be handled by 'off the shelf' packages.
    What we mistakenly call enterprise applications today are mainly departmental database apps. The reason why relational data is king is because corporations guard their data dearly and choose to mine it using technology like OLAP and Data Warehousing. The applications themselves are secoundary, so why all the ceremony?
    If you will forgive me, I think here you are looking backwards. Applications these days aren't secondary - there are substantial layers and processes above the database that add considerable value. For example, data is becoming (thank goodness) increasingly portable. Backward-looking approaches like Rails that assume that data will remain stuck in a particular database constrain what you can do with your data.
    For every concrete example of where Ruby would not be intrinsically appropriate I could mention at least 10 were it would be (All the apps I've delivered in the last five years could quite easilly have been written in RoR).
    Almost none of mine could. I have written websites that are international, and that have written software with substantial numerical work, for example. I am still trying to figure out what is the point of using a development language and approach that (as even you admit) seems to require that you write much additional support code, and even then you have to abandon its use in 1 in 10 projects. Why this fixation on RoR? Why not use Java in an agile way, saving you much coding, and allowing you to use the same language and techniques for closer to 100% of projects? Have you looked at Studio Creator? Is there one of those potential RoR projects that could not be done equally fast that way? What is the disadvantage?
    As for extending the application later, integration technology should ensure that Ruby has access to everything Java has access to.
    Well, if JRuby continues progessing at its current rate, I would agree.
    How do we get this integration technology? Well thats an opportunity to make a name for yourself by writing it open source :^).
    No, I think this is bad practice. You should not be using a particular language now based on the hope that you or someone else is going to somehow write something in future to enable integration with bigger systems, especially when there are other languages that have already solved this problem.
  275. Re: the dream of Eldorado[ Go to top ]

    Hi Steve, I think the gap between us is very close. Lieght weight Java is pointing the way forward. The people behind Ruby and RoR are taking the same type of thinking to the next logical stage. Things like Spring are based on the idea that Java and OO is more than heavy weight containers and J2EE. Ruby and RoR is based on the idea that pure dynamic, reflective OO is more than static typing, XML, complex frameworks and tools like Studio Creator. Are they there yet? to be honest I'm not sure (I would definately give RoR a go for some apps though). The argument in favour of Ruby (which are similar to the arguments in favour of Smalltalk) are clear. Time will tell whether it delivers. I think you will agree that it's worth watching. Paul.
  276. Re: the dream of Eldorado[ Go to top ]

    Hi Steve,

    I think the gap between us is very close.
    I think so to, but often that is where the debate is most interesting, or so I find.
    The people behind Ruby and RoR are taking the same type of thinking to the next logical stage.
    I don't agree. There is little new in RoR - much of it is backward looking, with an emphasis on SQL, relational databases and code embedded in HTML. I see a lot of true innovation in Java - the idea that data can be mobile and not just relational (with JDO), the idea that client-side remote presentation can be more than HTML (with JSF).
    Things like Spring are based on the idea that Java and OO is more than heavy weight containers and J2EE.
    Java has always been more than that.
    Ruby and RoR is based on the idea that pure dynamic, reflective OO is more than static typing, XML, complex frameworks and tools like Studio Creator.
    What is wrong with tools like Studio Creator? It seems to me that there is a sad common practice in open source to deride what you can't replicate. It is hard to make languages like Ruby fast, so they say that speed is not necessary. It is hard to make a good quality visual tool or IDE, so they claim that IDEs aren't necessary or somehow 'uncool'.
    Are they there yet? to be honest I'm not sure (I would definately give RoR a go for some apps though). The argument in favour of Ruby (which are similar to the arguments in favour of Smalltalk) are clear.
    I don't think they are. Smaltalk has a language design that makes it far safer and more refactorable than Ruby. I don't think all dynamic languages are equal.
    I think you will agree that it's worth watching.

    Paul.
    Yes, I agree. Thanks for the debate.
  277. Re: the dream of Eldorado[ Go to top ]

    the idea that client-side remote presentation can be more than HTML (with JSF).
    Are you confused Ajax with JSF? So far the big success stories of Ajax (such as GMail, Google Map etc.) does not have JSF in it. JSF was not started as a client side technology. Is it becoming a client side technology today?
  278. Re: the dream of Eldorado[ Go to top ]

    the idea that client-side remote presentation can be more than HTML (with JSF).


    Are you confused Ajax with JSF? So far the big success stories of Ajax (such as GMail, Google Map etc.) does not have JSF in it. JSF was not started as a client side technology. Is it becoming a client side technology today?
    Have you confused Ajax with JSF? So far the big success stories of Ajax (such as GMail, Google Map etc.) do not have JSF in it. JSF was not started as a client side technology. Is it becoming a client side technology today?
  279. Re: the dream of Eldorado[ Go to top ]

    the idea that client-side remote presentation can be more than HTML (with JSF).


    Are you confused Ajax with JSF?
    No.
    So far the big success stories of Ajax (such as GMail, Google Map etc.) does not have JSF in it.
    That is hardly surprising. Good integration of AJAX with JSF is pretty new. GMail etc. have been out for some time.
    JSF was not started as a client side technology. Is it becoming a client side technology today?
    JSF has always included client-side technologies. What else is HTML but a specification for client-side rendering? JSF implementations also include the ability to render client-side GUIs based on a range of client-side technologies - SVG, JSP, AJAX, WML etc.
  280. Re: the dream of Eldorado[ Go to top ]

    JSF has always included client-side technologies. What else is HTML but a specification for client-side rendering? JSF implementations also include the ability to render client-side GUIs based on a range of client-side technologies - SVG, JSP, AJAX, WML etc.
    SVG? Where in the JSF spec is SVG included? or which part of the GlassFish server (Java EE5 RI) supports SVG? As AJAX, WML (and HTML). Which framework does execlude them? In essence, they are all in the DHTML family. JSF has not enjoyd much success in the market on the HTML/WML front, I am afraid, comparing to other Web frameworks, including the dead old Struts. How successfully JSF can integrate with Ajax is still yet to be seen. BTW, a lot of people miss the point that both Struts 1.1 and ASP.NET 1.1 were released in 2003 (even MSDN envied the success of Struts at that time), and call ASP.NET a newer technology (than Struts). Rod Johnson is deadly right in saying that the IT industry is very much like the fashion industry. But the market is slowly making Java out of fashion in favour of .NET, even a few try desprately to keep JSF (and Java EE in that matter) in the show.
  281. Re: the dream of Eldorado[ Go to top ]

    SVG?
    Where in the JSF spec is SVG included?
    The point is that JSF has pluggable renderers. There is no reason you can't render in SVG, or anything else you can imagine.

    JSF has not enjoyd much success in the market on the HTML/WML front, I am afraid, comparing to other Web frameworks, including the dead old Struts.
    For a relatively new technology, JSF has actually enjoyed a great deal of success.
    How successfully JSF can integrate with Ajax is still yet to be seen.
    It's already being done - and quite successfully.
    But the market is slowly making Java out of fashion in favour of .NET, even a few try desprately to keep JSF (and Java EE in that matter) in the show.
    Now you're just being silly. It's fine to debate the relative merits of the two technologies, but let's show a little respect for each other. The fact is, there is plenty of room for both Java and .NET developers, and that will be the case for the foreseeable future.
  282. Re: the dream of Eldorado[ Go to top ]

    Now you're just being silly. It's fine to debate the relative merits of the two technologies, but let's show a little respect for each other. The fact is, there is plenty of room for both Java and .NET developers, and that will be the case for the foreseeable future.
    It is YOU who ARE silly in denying the widespread existence of fashion mentality in the industry. Simulating the desktop paradigm (on the server side) was done in ASP.NET to entice the VB6 crowd (That was what Microsoft said in the "ASP+" days). Suddenly it becomes a fashion for many JSF advocates.
  283. the latest fashion[ Go to top ]

    Your absolutely right. Working on the department level I have more leeway to use advance technologies (even beta) and user interfaces. The XMLHttpRequest object (called Ajax novadays) has been a tool for a looong time, Lately we have been experimenting with XQuery and the new CSS selectors in IE7. Microsoft CRM 3.0. Everybody is looking froward to Windows Vista with XAML. You don't use sunglasses from last year do you? Certainly not. Regards Rolf Tollerud
  284. Re: the latest fashion[ Go to top ]

    You don't use sunglasses from last year do you? Certainly not.

    Regards
    Rolf Tollerud
    Are you saying simulating the desktop paradigm on the server side is no longer fashionable. Now we are doing it in the browser (with Ajax, of course)?
  285. Re: the latest fashion[ Go to top ]

    Precisely. An Ajax interface does not require a full blown .NET server, some simple PHP/REST methods do the job. At the time .NET/C# is mostly used to glue together MS server products. But IE7+ and WinFX with Windows Communication Foundation (WCF), Windows Workflow Foundation (WF) and Windows Presentation Foundation - WPF/Avalon/XAML (dear child has many names :) will change all that. Regards Rolf Tollerud
  286. Re: the dream of Eldorado[ Go to top ]

    JSF has always included client-side technologies. What else is HTML but a specification for client-side rendering? JSF implementations also include the ability to render client-side GUIs based on a range of client-side technologies - SVG, JSP, AJAX, WML etc.


    SVG?

    Where in the JSF spec is SVG included? or which part of the GlassFish server (Java EE5 RI) supports SVG?
    They aren't in the spec. What is in the spec is the principle that JSF can render almost any client-side presentation technology you like.
    Which framework does execlude them? In essence, they are all in the DHTML family.
    You need to look further. There are also JSF implementations that have rendered to technologies such as VT-100 text terminals! It is extremely flexibile.
    JSF has not enjoyd much success in the market on the HTML/WML front, I am afraid, comparing to other Web frameworks, including the dead old Struts.
    I am afraid it has, actually. Its use has grown considerably over the past year, and there is a huge amount of exciting work by vendors and developers to implement JSF and extend it in new ways - Facelets, Seam are popular extensions, then there are the exciting AJAX-enabled implementations: ICEFaces. Who said struts was dead anyway?
    How successfully JSF can integrate with Ajax is still yet to be seen.
    No - it integrates very well. Check out the ICEFaces announcement on TSS recently. Check out the demos. The beauty of using JSF is that you don't have to code any of the Javascript yourself.
    Rod Johnson is deadly right in saying that the IT industry is very much like the fashion industry.
    Which is why we need to keep up-to-date with things. What may have seemed not-so-popular a year or so ago, can become much more widely used and full of exciting developments pretty quickly - like JSF.
    But the market is slowly making Java out of fashion in favour of .NET, even a few try desprately to keep JSF (and Java EE in that matter) in the show.
    This is a very out-of-date misreading of the situation. After a slow start, JSF is doing very well, and J2EE is strongly holding its own against .NET. There has been little change in the relative market shares as far as I have seen for a long time.
  287. Re: the dream of Eldorado[ Go to top ]

    "J2EE is strongly holding its own against .NET. There has been little change in the relative market shares as far as I have seen for a long time" It is true that J2EE and .NET's marketshare has been constant for a while. IMO that is because of the rising popularity of Ajax. Don't think that it will be permanent though. You are akin to people in a boat in the center of the hurricane.
  288. Re: the dream of Eldorado[ Go to top ]

    "J2EE is strongly holding its own against .NET. There has been little change in the relative market shares as far as I have seen for a long time"

    It is true that J2EE and .NET's marketshare has been constant for a while. IMO that is because of the rising popularity of Ajax. Don't think that it will be permanent though. You are akin to people in a boat in the center of the hurricane.
    What has AJAX to do with it? It is entirely neutral with regard to which of these frameworks you use - both offer APIs and tools for development involving AJAX, so the choice of framework must be on other criteria.
  289. Re: the dream of Eldorado[ Go to top ]

    Oh come on Steve. As this debate has shown it is more a culture conflict than a language conflict. We on the this side so to speak, set higher priority to the user interface and downgrade the server importance. The Big Java Servers/EJB developers on the other hand are as a group not positive to Ajax. Peter Lin for instance has never done an advanced user interface in all his life - according to himself. Regards Rolf Tollerud
  290. Re: the dream of Eldorado[ Go to top ]

    Oh come on Steve. As this debate has shown it is more a culture conflict than a language conflict.
    Indeed it is. I support a culture of freedom, where developers can choose different vendors and platforms for their products - somewhat different from the Microsoft culture.
    We on the this side so to speak, set higher priority to the user interface and downgrade the server importance.
    Servers are pretty useless without a good user interface to them.
    The Big Java Servers/EJB developers on the other hand are as a group not positive to Ajax.
    You really should try and keep up-to-date with these things. JSF is included in the latest release of JEE, and the new Java BluePrints for this release of JEE includes AJAX examples. Do you have any actual evidence that somehow connects use of EJB with a dislike of AJAX?
    Peter Lin for instance has never done an advanced user interface in all his life - according to himself.
    Which is irrelevant. Actually, I really should not get sucked into this kind of discussion - it goes round in circles, and off at irrelevant tangents. You have your world-view and I am unlikely to change it.
  291. Re: the dream of Eldorado[ Go to top ]

    Oh come on Steve. As this debate has shown it is more a culture conflict than a language conflict. We on the this side so to speak, set higher priority to the user interface and downgrade the server importance. The Big Java Servers/EJB developers on the other hand are as a group not positive to Ajax.
    Big J2EE developers over-architecting with EJBs, as detailed here: http://thedailywtf.com/forums/thread/75070.aspx ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  292. the competetive urge[ Go to top ]

    There you have it. It is not a language issue. Even Microsoft developers manage to do it the EJB way sometimes.
  293. Henrique, I often find myself in the same situation as the guy with Queen Eliabeth summercottage. For instance Peter Lin he will not discuss anything that is not apliciable to the worlds biggest finacial companies.. Normally if you are a British citizen (and therefore sensible and with proportions) you politly assume implicit in a discussion that you talk about the 80% most common cases - not the 20%. I do not know Brazil, but in USA 80% of the people work in companies with less than 5000 employees. U.S. Census Bureau http://www.census.gov/epcd/www/smallbus.html Most common is to work in firms with 500-1000 employees. Furthermore we can assume that they already have bought their ERP and payroll systems. (the golden days has gone when they hired IBM to custommake those thank god). So the Microsoft way is only to consolidate data. That is the structure and normalisation of the databases is decided by management, besides of that, everyone (well not everyone of course :) is supposed to write or buy their own applications. If you **** it up you stand responsible. Most of the time the applications are only thin layers around the database, as you can imagine. I understand that the members of TSS are horrified by this but it works very well in practice. It usually pays to hire people you can have confidence in. Regards Rolf Tollerud
  294. You're too funny Rolf. I don't talk about small apps for a simple reason. It's been a long time since I've worked on them, so I'm out of touch with small apps. Could I talk about it and state a lot of BS? Sure, but what's the point of that. I talk about the stuff I do know and have been working on the last few years. For better or worse, I've had to deal with large scale issues, so that's my bias. I make it pretty clear it's my bias opinion based on first hand experience, so I make no claim my experience applies to anyone else. Small businesses make up a huge percent of the US economy, so by no means is it trivial. peter
  295. Rolf, even in the case of small/mid sized companies, the kind of problem I am talking about may happen. You say MS tools are just to consolidate, and that payroll, ERP, etc systems have already been created and are available (almost) off-the-shelf. What about those systems which are specific to the client's area? In my case I work for a telecom company, who has very specific processes, and these sometimes are similar to other areas (equipment inventory/maintenance/logistics) and some are specific to telecom (circuit planning/provisioning/recovery), for example. There are software packages to deal with these processes, but they are usually very expensive and demand lots of customization, since every company operates differently because of legal, technical or human factors. So most companies prefer to build them to their specifications. And even small companies with very specific and unique processes won't find ready-to-use packages in the market and so must build complex apps to support their everyday operations, which btw are not just reporting systems. I wouldn't feel confortable leaving those systems in the hand of power-users either. Ok, you may say that those don't fit you 80% rule too. Well, I happen to work on the 20%, so I'd rather talk about what I know... ;) Besides, the 80% seems rather boring and unchallenging to me, I'd gladly leave it to power-users in this case, as their harm will be limited! :) But whatever the situation, it all boils down to what Paul said: we should do the simplest that works now. But I'd follow Steve's advice too: build it so it can grow tomorrow. Should be as simple as that.
  296. Of course Telecom work is not something you can leave to powerusers we can agree on that. But about what work is more satisfying you shouldn't be so sure. I like to work with that kind of people, they are often more intresting than the typical computer geek. Besides I thrive in the role as hero and besserwisser! :) Also I like to be in control and not only just a little pawn in a large project. To everyone as he deserve. Regards Rolf Tollerud
  297. Agility[ Go to top ]

    hi Henrique,
    But whatever the situation, it all boils down to what Paul said: we should do the simplest that works now. But I'd follow Steve's advice too: build it so it can grow tomorrow. Should be as simple as that.
    It should be that simple. but what I believe we have is a cutural problem. As professionals we tent to spend a lot of time telling users what they need from us, rather than actually listening. I think there is a lot to be learnt from the success of things like Visual Basic and MS Access. End user departments found these technologies liberating. Microsoft do seem to understand business in a way that say Sun, IBM and Oracle do not. FACTS: 1. Most business opportunities are transient. 2. The business do not know what they want until they see it (iterative, small releases with feedback) 3. Your enterprise wide 'strategy' will always be wrong. Just to expand on this last point. What happes to your JEE enterprise strategy when your company suddenly gets bought out by a company that exclusively uses .NET? The truth is there is no ideal master plan. IT infrastructure needs to be able to change and adapt organically in the same way that companies and people do. I think this is where VB and MS Access become un-stuck. They are fast out of the blocks but they struggle to faclilitate change, so the intial speed in unsustained (they tend to grined to a halt rather quickly). So what we really need is Agile thinking and truly Agile tools. People who think in an Agile way will select/create the Agile tools they need. I don't see our current crop of IT vendors as Agile Thinkers, so IMO it will be down to us, the developer community. Debates like this are a step in the write direction. Paul.
  298. Facts vs Opinions[ Go to top ]

    FACTS:
    No, opinions.
    1. Most business opportunities are transient.
    I suppose that depends on your industry, but I'm tempted to say that's patently false. Most opportunities involve reducing cost and/or increasing value of products and/or services. Temporary boosts in these areas are distractions.
    2. The business do not know what they want until they see it (iterative, small releases with feedback)
    I'm not surprised if it thinks all of it's opportunities are transient. The business has some objective it wants to accomplish, and building an application is part of how it expects to accomplish it. It may be communicate this objective, but it either has it or has no business building an application. That's the "why" of building an application. The business also has and idea of how it expects the application to help it meet its objective. Those are the requirements. That's the "what" of building an application. Again, it may not articulate it, but it probably knows. Then there's the "how," the action design and implementation of the application. The business has no idea about this, although it may loudly express opinions about it. It does this because communicating the "why" and "what" is too painful. The problem isn't what the business knows. The problem is "the business" and "IT" speak entirely different languages. So instead of directly communicating, "the business" and "IT" gather around a "working" application and "the business" makes grunts and gestures to indicate how pleased or displeased it is.
    3. Your enterprise wide 'strategy' will always be wrong.
    It will only always be wrong if it is so precisely defined that it isn't really a strategy. It's a rulebook. Use version X of product Y from vendor Z.
  299. Re: Facts vs Opinions[ Go to top ]

    Hi Erik, Since you refute my facts then I guess that you have opinions of your own:^) Perhaps I should have explained myself further (or you could have requested further explantion)
    1. Most business opportunities are transient.
    This one spins on the definition of opportunity and transient. First opportunity can be several things. The one I see the most is the opportunity to improve working efficiency or accuracy, basically doing the daily work better. The people that know of these "opportunities" are usually at the bottom of the organisation "the workers". Transient can define any period of time from secounds to perhaps several years and of course everything in between. My point is that the window of opprotunity is normally quite short. The fix/improvement is needed now and often next week is too late, for various reasons (e.g. after next week it will be too late for the Commissioning Manager to factor the improvement into his anual bonus :^)).
    2. The business do not know what they want until they try it (iterative, small releases with feedback)
    You talk about objectives. How do you know the objectives you've plucked out the air are the right ones? The proof of the pudding is always in the eating (ROI). If you don't test your decisions how do you know you are making the right ones? It is like asking some one to buy a suit without ever trying it on, yet we ask the business to do this all the time.
    3. Your enterprise wide 'strategy' will always be wrong.
    Strategy is an interesting term. For instance a strategy could be not to have a strategy. In fact this is the best IT strategy I've come across :^). Seriously though, the tone of your response is indicative of the cultural problem I refer to in my post. We tend to want to fit the business around the IT rather than being willing to fit the IT around the business (people). Most IT professionals feel they know how the business should be run, yet they've never run a real world business in their lives. They want to fit everything neatly into square boxes joined by straight lines. I think this is at the route of the diference in language between business people and IT that you speak of. Paul.
  300. Re: Facts vs Opinions[ Go to top ]

    Hi Erik, Since you refute my facts then I guess that you have opinions of your own:^) Perhaps I should have explained myself further (or you could have requested further explantion)
    Sorry, I was (well, am) in a bad mood. Anyway, I'll try to be more civil. And yes, I am expressing opinions. Opinion based on experiences, just like you. First, on transient:
    The fix/improvement is needed now and often next week is too late, for various reasons (e.g. after next week it will be too late for the Commissioning Manager to factor the improvement into his anual bonus
    I know you're half joking, but I almost posted a rant on this - too many projects are launched in an attempt to produce short-term "success" in order to yield personal or departmental gain. The opportunities usually aren't transient because the business changes, opportunities are transient because you must obtain funding during the short window where some executive is focused on the problem, and your solution must fit within his attention span. The problem is these short-term successes turn into operational disasters. Business processes are built based on short-term subsidies provided to "launch the process" and subsequently collapse when the subsidies goes away.
    First opportunity can be several things. The one I see the most is the opportunity to improve working efficiency or accuracy, basically doing the daily work better. The people that know of these "opportunities" are usually at the bottom of the organisation "the workers".
    I agree, with most being about 70%.
    How do you know the objectives you've plucked out the air are the right ones?
    Very good question. One of my personal favorites is value stream mapping, because it's fairly light weight. Find the bottlenecks and find the places where there are unnecessary cycles. There are lots of ways. Of course they don't make you know that the objectives are correct, but they increase your certainty. Objectives should also be tangible and solution agnostic, for example reducing cycle time for a process. "Build a system to do X" isn't an objective.
    If you don't test your decisions how do you know you are making the right ones?
    How do you prioritize your tests without doing analysis? My experience is that pushing into development activities too fast leads to a lot of zombie applications. Too many people use them to kill them off, not enough use them to justify sufficient funding for maintenance, the established reputation is too poor to earn funding for enhancements. So they just plod along, sapping the life out of other projects because people have to charge their time against something when they work on them.
    It is like asking some one to buy a suit without ever trying it on, yet we ask the business to do this all the time.
    Asking IT to build an application without clear objectives is like asking for clothing without specifying whether you're going to the tropics or the arctic. A business should have a decent idea what it expects to get out of an investment and how it expects to get it before making the investment. It should also have an idea what the recurring costs of ensuring a return are going to be.
    Strategy is an interesting term. For instance a strategy could be not to have a strategy. In fact this is the best IT strategy I've come across :^).
    Strategy is important, but usually done wrong, and strategy is better than a bad strategy. A couple key aspects of IT strategy are build vs buy, outsource vs insource, and domain experts vs technology experts. Building software requires a different (but overlaping) set of competencies than buying software. Likewise with outsourcing vs insourcing. I personally lean towards inhouse bespoke development, because I think it's important the applications closely match the processes they automate and customizing off-the-shelf apps costs a fortune. I'd also rather write code than SOWs and contracts. But the point is an organization needs to decide what it's strategy is so it can develop competencies support that strategy. The average developer makes a bad contracts manager, and the average contracts manager makes a bad developer. I don't think standardizing on Java/.NET/Unix/Windows/Ruby is a strategy.
    Seriously though, the tone of your response is indicative of the cultural problem I refer to in my post. We tend to want to fit the business around the IT rather than being willing to fit the IT around the business (people). Most IT professionals feel they know how the business should be run, yet they've never run a real world business in their lives. They want to fit everything neatly into square boxes joined by straight lines. I think this is at the route of the diference in language between business people and IT that you speak of.
    The problem is quality software is deterministic (ignore stochastic algorithms for the moment...), and business is not. Computers can perform billions of complex calculations faster than a person can press a single key. People can make intelligent decisions that are impossible for computers in seconds. Unfortunately, the line between logic and intuition is not always clear. Good software frees the user from mechanistic logic and enables him to focus on his intuition. Bad software either tries to force the intuitive into straight lines and square boxes, or simply abandons real logic and simply acts as a datastore (i.e. CRUD applications - ok, so sometimes CRUD is what's needed - but often times pure CRUD destroys efficiency).
    I think our primary disagreement is how much should be learned through analysis and how much through experimentation. In my organization, application development/deployment is often used as a way to show tangible results when fixing/improving a business process when the process owners either don't know to improve the process or simply don't know how the make those improvement tangible. Consequently, a fair amount of money gets wasted building and maintaining applications that aren't really needed. If you're going to experiment, you need a hypothesis (how the appliation is going to improve business performance), and you need the experiement to have a measurable result that will support or debunk the hypothesis. I believe in agile development as a science rather than agile development as a craft.
  301. Re: Facts vs Opinions[ Go to top ]

    In my organization, application development/deployment is often used as a way to show tangible results when fixing/improving a business process when the process owners either don't know to improve the process or simply don't know how the make those improvement tangible.
    To be clear, the "tangible result" is the application - not some business improvement.
  302. Re: Facts vs Opinions[ Go to top ]

    In my organization, application development/deployment is often used as a way to show tangible results when fixing/improving a business process when the process owners either don't know to improve the process or simply don't know how the make those improvement tangible.


    To be clear, the "tangible result" is the application - not some business improvement.
    Hi Erik, This is a real interesting one. And A subject you're passionate about I can tell. I think the issue is about pace of improvement and how organisations learn and grow. What I'm suggesting is that organisations tend to explore ideas, some bear fruit and are built upon, others prove to be less fruitful and wither and die. If this is the way with good business ideas, why should the IT be any diferent? After all, the IT is just another business idea. No one knows which IT systems are going to to deliver real benefits and which ones won't. Our job is to build the systems. Assuming that they are built properly, it will require visibility and accountability to allow senior management to identify which departments and systems are succeeding and which aren't. The successful departments (people) will prosper and their ideas (IT) will get rolled out to other parts of the organisation. Companies aren't planned, optimal, uniform, logical entities, yet we expect to impose IT systems that are all these things. The end result is we try to impose systems top down rather than growing them organically, bottom up. Senior management like to believe that their organisations are "optimal", but the workers know this isn't the case. This tension exists in all businesses. It is the business that will need to address this tension, not IT. We can advise, but in the end our job is to estimate (cost/benefit) and deliver (build working software). I would love to talk more about this subject. To give you a feel, I've worked on systems were the users were adamant that a certain feature was absolutely needed. When asked what they wanted in the first iteration (2 weeks) a simple login screen or this feature, the answer was the screen. We kept on prioritising requirements like this and delivering fortnightly with the ever so needed feature continuingly being pushed down the priority. Eventually the system went into production with the really needed feature still in the backlog. I knew (guessed) at the beginning that this really needed feature wasn't needed at all, but it took exploration and discovery for the business to come to the same decision for themselves. This may seem long winded and time wasting to us, but being forced to build the feature which was a clearly stated business goal and the resultant mis-use of this feature in production would of cost the business a lot more. Exploration and discovery may look sub-optimal, yet it is the only way to delivering true business value. Like I said, the business do not know what they want until they see it working. Paul.
  303. Re: Facts vs Opinions[ Go to top ]

    Hi Erik,
    Exploration and discovery may look sub-optimal, yet it is the only way to delivering true business value. Like I said, the business do not know what they want until they see it working.
    I thought I should tell you a bit more about the "really needed feature". The application was to manage a process that spanned three departments. Now the departments didn't trust each other, having developed a culture of blame, where one department would blame the other for failures in the process. So due to this lack of trust they wanted "security". What they meant by security is that they didn't want each other to see other departments data. No one wanted to give the other departments a stick to beat them up with. It dawned on me quite early on that once they were all sharing data, that the level of trust amongst them would increase, also they would be less likely to blame since they could see the problems facing each other quite clearly. Yet they were adament that they required "security" (departmental based authorisation). Before we could write the software the departments had to start talking to each other, after all we could not produce working code until they did, and we had to have something working every two weeks. No one department wanted to be blamed for the development team sitting on their hands for two weeks, they all knew that programmers got payed very well and were expensive :^). So they started talking. We built the system, and they tried it out and talked some more. Eventually when we pointed out that to retrofit all this user authorisation what going to take a long time, they said well we don't think we actually need that right now! There is nothing stranger than folk, and no IT manual or text book on Systems Analysis could have dealt with this one. The real issue was a pure business (people) one. Paul.
  304. I knew (guessed) at the beginning that this really needed feature wasn't needed at all, but it took exploration and discovery for the business to come to the same decision for themselves. This may seem long winded and time wasting to us, but being forced to build the feature which was a clearly stated business goal and the resultant mis-use of this feature in production would of cost the business a lot more.
    I thought I should tell you a bit more about the "really needed feature". The application was to manage a process that spanned three departments. Now the departments didn't trust each other, having developed a culture of blame, where one department would blame the other for failures in the process. So due to this lack of trust they wanted "security". What they meant by security is that they didn't want each other to see other departments data. No one wanted to give the other departments a stick to beat them up with.
    What you're talking about is a business constraint, not a business objective. And, incidentally, I've dealt with essentially the same one - both false and real - on many occasions. For example, a few years ago my employer purchased another company. In order for the aqcuisition to receive regulatory approval, the company had to agree to keep the business unit that I work for and one of the acquired business units very strictly separated for a number of years. Much of the separation involves disallowing certain transfers of technological information. One of my employer's business goals is to de-silo the business and encourage the sharing of IP across business units. Except for between my business unit and this other one, in which case it will be heftily fined if inappriopriate transfers take place. This makes for some very interesting meetings, and some interesting requirements for applications that are designed to widely disseminate information. In this case the constraint (certain information cannot be shared across these two business units) and the goal (make IP as widely accessible across the corporation as possible) run directly contrary to one another, but the constraint is very real. Last year we had a project almost completely grind to a halt because we failed to realize the above constaint applied to it. None of the project stakeholders were particularly interested in security. The idea was to share information, not hide it. My first point is there is a significant, although often times subtle, logical difference between a business's goals and the contraints the business is subject to while pursueing them. My second point is that sometimes the priorities of the stakeholders involved in a project have critical differences from the priorities of the business as a whole.
    This is a real interesting one. And A subject you're passionate about I can tell. I think the issue is about pace of improvement and how organisations learn and grow. What I'm suggesting is that organisations tend to explore ideas, some bear fruit and are built upon, others prove to be less fruitful and wither and die.
    I'm not arguing that exploration isn't valuable, I'm arguing that it should be structured, with clear objectives. Just like software, objectives can be defined and built incrementally. Indeed, learning is an objective, and a pretty good one at that - assuming you have a set of questions that you want answered, and one result of a learning activity can be more questions. But regardless of your objective, you need clear success criteria. Otherwise you don't know where you're going, and if you get there you likely will not know it.
  305. Hi Erik, I'm not sure whether I can truely tell the difference between a business goal and a business constraint. I'm sure of the difference between a technical goal and a technical constraint, but as for using these terms in the business context I'm not sure if they apply.
    I believe in agile development as a science rather than agile development as a craft.
    I see development as part science (the language of objectives, constraints, performance etc) and part art/craft (the language of trust, fear, buy-in, confidence, accountability etc). I believe Agile development addresses both aspects by adressing relationships (customer/developer collaboration) and measuring results (stories points and velocity). Organisations are all about people. People are very good at using rational scientific language (objectives, constraints, bottle-necks etc), to obscure political issues (fear, lack of trust, allegiances, tribalism etc). I liked your story and I tend to agree with everything you say, I'm just choosing to emphasise the people issues which tend to be less tangible and hence less measurable. These people issues make or brake projects. I'm sure you will agree. If I could find a way to gain objective measures on everything and using that to drive development decisions I would (assuming that the stakeholders would be positively influenced by objective measures, don't laugh I've experienced the contrary :^)). Untill then, the skill IMO is appreciating both the people and technical issues and knowing how to deal with both. Paul.
  306. Re: the dream of Eldorado[ Go to top ]

    The Java crowd and and the Open Source Unix people are reminiscences from the same source - the totalitarian age of the big central computers.
    Oh man, what's gotten into you?
  307. what's gotten into me?[ Go to top ]

    To give back a little, no more. You can stop waisting your time longing back to the time when everybody was taken by surprise by the the Web and had a great time to make fun of Microsoft, pretending they had developed Windows 98, VB6 and their personal productive systems for internet.. Today Window server installations have surpassed Unix up from 0, zero, nada. Vista with XAML is around the corner, MS Smartphones are top of the line (check out the new Hermes next month), we have XBox 360 and multimedia, and so on. And Sun - the company with "Unix workstations" :) that was saved by the web miracle with borrowed OS and borrowed hardware with a non-technician golf playing boss only slightly less arrogant and pretentious than Sharon Stone, and Sun - and Sun, what happened to them?
    In one of Jonathan Schwartz's first acts as CEO, Sun Microsystems has announced that they are cutting up to 5,000 jobs over the next 6 months. The company plans to sell property it owns in Newark, Calif., and to exit leases at a site in Sunnyvale.
    http://www.cbc.ca/story/business/national/2006/05/31/sun-wed.html There is a justice, after all. Rolf Tollerud
  308. Re: what's gotten into me?[ Go to top ]

    To give back a little, no more.
    I'm sure we are all grateful, but I think we can save you a lot of time and trouble. You have been coming on here and forecasting the decline of Java, the death of Sun, and making delightfully outrageous claims about the supposed disaster that is EJB so often that it must be getting tiresome for you. Tell you what - we could put together some script to generate your posts for you. All we would need to do is to combine the following phrases at random: (1) 'Sun are doomed'. (2) 'EJB is the greatest disaster in the history if IT - it has cost [insert random number] trillion dollars'. (3) '.NET is part of the march to world freedom'. (4) Some random irrelevant quote from a literary or historical figure. Then all we would need to do is generate some random 'fact' that makes no sense at all (remember your claims that there were no successful J2EE/EJB sites?), and add some random wild prediction (remember your claim that .NET was crushing out Java from the job market and would take over by the end of (was it last year? I forget)). This should be easy to write, and would save you a lot of time.
  309. By the way, why nobody never mentions Borland Delphi at any of these discussions? I think that Delphi was the best ever tool for developing Windows applications. VB never managed to come anywhere near what Delphi could do. Disclaimer: I like Microsoft. I like their Operational System, their Office Suite, their games - and their C++ Compiler and their C++ framework (MFC). I also like .NET, especially when it comes to productivity. But not as tool for newcomers. They become addicted. And blind. And they end up producing bad quality software.
  310. Rolf bot[ Go to top ]

    I am really beginning to adhere to the Rolf bot theory. He almost never posted here during the last year but here comes an article with the word .Net into it and you get about 10 posts of him rambling how bad EJB 2 was. Something like : Look for ".Net" If found { Give some crazy stats Say how bad was EJB 2 Predict Java death to .Net because of [insert Microsoft's new product name here] Promote Microsoft as being God and Open Source as being communist } It's really getting old but at least it's distracting :)
  311. Boring[ Go to top ]

    I am really beginning to adhere to the Rolf bot theory. He almost never posted here during the last year but here comes an article with the word .Net into it and you get about 10 posts of him rambling how bad EJB 2 was.

    Something like :
    Look for ".Net"
    If found {
    Give some crazy stats
    Say how bad was EJB 2
    Predict Java death to .Net because of [insert Microsoft's new product name here]
    Promote Microsoft as being God and Open Source as being communist
    }

    It's really getting old but at least it's distracting :)
    All this slap stick stuff is getting a bit boring. All this partisan Vendor X's products are better than Vendor Y's by people who have no good reason to represent either. The truth is that the IT industry is on big scam with the vendors taking the biggest slice of the pie. Has anyone given a thought to the end customer? They don't care that you've spent the last 5 years learning the API's of Vendor X, and now feel threatened. All they want is a working solution to their problem. FACT: Most software projects deliver less then half what was promised at twice the cost and in twice the time. Have any of us in the IT industry got anything to be proud of? I don't think so. Until the developer community wakes up and realises that we do not have a divine right to get paid. And forums like this change their focus to discussing how we deliver true value to our customers rather than arguing over paper tigers and blind allegiance to vendors then nothing will change IMO. I do not consider myself either a .NET programmer or a JEE programmer, I'm a pragmatic programmer and I will use what ever tool gets the job done. Increasingly I'm finding that to escape the vendor marketing noise (Aqualaogic this, WorkShop that, SOA, WS-*, etc) I'm drawn to open source frameworks. A lot of pragmatists are experiencing the same. BTW. Ever since Microsoft came out with .NET, Sun has been aping every API Microsoft comes up with. The ditching of RMI/IIOP for SOAP and the focus on "SOA" (which has got to be the worst marketing term of the decade, I still don't know what it means). The truth is that Java and C# are pretty similar, also you can use many of the same open source API's on both platforms (Spring and Hibernate). So why the name calling? Grow up and deal with the real issues. My other point is all this talk about "enterprise" when everyone knows that all we do is put a web front end on top of a database. These use to be known as departmental applications. True enterprise apps in my experience still use C/C++ (Tuxedo), and you won't find either C# or Java in the datacenter (before the Java grid guy pipes up, I should say that you hardly find Java in the datacenter, I've never seen a job advertised to do say Payroll or ERP in Java). All these API's and talking the industry up, when in the end all that is delivered is CRUD web apps with maybe some integration with legacy systems. More I think about it things like LAMP and RoR make a lot of sense. Who needs .NET or JEE for CRUD? Other than the vendors looking to fleece naive customers I mean? Paul.
  312. Re: Boring[ Go to top ]

    I am really beginning to adhere to the Rolf bot theory. He almost never posted here during the last year but here comes an article with the word .Net into it and you get about 10 posts of him rambling how bad EJB 2 was.

    Something like :
    Look for ".Net"
    If found {
    Give some crazy stats
    Say how bad was EJB 2
    Predict Java death to .Net because of [insert Microsoft's new product name here]
    Promote Microsoft as being God and Open Source as being communist
    }

    It's really getting old but at least it's distracting :)

    All this slap stick stuff is getting a bit boring. All this partisan Vendor X's products are better than Vendor Y's by people who have no good reason to represent either.

    The truth is that the IT industry is on big scam with the vendors taking the biggest slice of the pie. Has anyone given a thought to the end customer? They don't care that you've spent the last 5 years learning the API's of Vendor X, and now feel threatened. All they want is a working solution to their problem.

    FACT: Most software projects deliver less then half what was promised at twice the cost and in twice the time. Have any of us in the IT industry got anything to be proud of? I don't think so.

    Until the developer community wakes up and realises that we do not have a divine right to get paid. And forums like this change their focus to discussing how we deliver true value to our customers rather than arguing over paper tigers and blind allegiance to vendors then nothing will change IMO.

    I do not consider myself either a .NET programmer or a JEE programmer, I'm a pragmatic programmer and I will use what ever tool gets the job done. Increasingly I'm finding that to escape the vendor marketing noise (Aqualaogic this, WorkShop that, SOA, WS-*, etc) I'm drawn to open source frameworks. A lot of pragmatists are experiencing the same.

    BTW. Ever since Microsoft came out with .NET, Sun has been aping every API Microsoft comes up with. The ditching of RMI/IIOP for SOAP and the focus on "SOA" (which has got to be the worst marketing term of the decade, I still don't know what it means). The truth is that Java and C# are pretty similar, also you can use many of the same open source API's on both platforms (Spring and Hibernate).

    So why the name calling? Grow up and deal with the real issues.

    My other point is all this talk about "enterprise" when everyone knows that all we do is put a web front end on top of a database. These use to be known as departmental applications. True enterprise apps in my experience still use C/C++ (Tuxedo), and you won't find either C# or Java in the datacenter (before the Java grid guy pipes up, I should say that you hardly find Java in the datacenter, I've never seen a job advertised to do say Payroll or ERP in Java).

    All these API's and talking the industry up, when in the end all that is delivered is CRUD web apps with maybe some integration with legacy systems. More I think about it things like LAMP and RoR make a lot of sense. Who needs .NET or JEE for CRUD? Other than the vendors looking to fleece naive customers I mean?

    Paul.
    Well it's all come to the software expected lifetime if you ask me. For instance, RoR is cool but I'm not comfortable to use it in a system that is going to last more than 10 years and see many crazy changes (think about government law reforms) even if the application is just a Web front end. You never know what a new appointed minister is going to do with his pen... So I'm all for agility but not at the architectural level. I prefer to stick with one development environment and a couple of template architectures.
  313. Re: Boring[ Go to top ]

    In hear your argument, but if you think it through you will realise that it's based on FUD. So you need features that you believe say Ruby or PHP isn't suited to, then great integrate your Ruby App with a system that provides the service you need. Isn't this what all the SOA talk is about? Think about it, if we had to deliver all our application in one language on one platform today, then we would write everything in PL/SQL in the database, and users would be presented with an SQL prompt and Oracle reports as a user interface. We already integrate across technologies today, with DHTML/Javascript on the client, Java on the server and SQL in the database. The Agile approach is to build for today, refactor for tomorrow. I can forsee no circumstance where this approach is not adequate. Why speculatively invest in a future that may never materialise? The chances are that the guess you make today will be wrong. This is common mistake that leads to over-engineering. It is possible to create an enterprise wide architecture that avoids speculative over-engineering. A lot of top corporations do this today, with Java/J2EE for front end service integration and delivery, Tuxedo (or similar) as the enterprise messaging backbone, and C/C++ in the back-end. In such an architecture, I see no reason why Java/J2EE (or .NET) could not easily be replaced with something like Ruby at the front end. The advantage of this functional splits is that business services can be delivered quickly in the front end. If over time these services need to become more robust or more performant, or require true enterprise presence then they can be migrated (refactored) to the back-end (incidently there is also a good argument for replacing C/C++ in the back-end with say Java over time, but of course that may mean re-writing a lot of legacy code that already works, so why do it?). Thinking out of the (vendor) box. Paul.
  314. Re: Boring[ Go to top ]

    In hear your argument, but if you think it through you will realise that it's based on FUD.

    So you need features that you believe say Ruby or PHP isn't suited to, then great integrate your Ruby App with a system that provides the service you need. Isn't this what all the SOA talk is about?

    Think about it, if we had to deliver all our application in one language on one platform today, then we would write everything in PL/SQL in the database, and users would be presented with an SQL prompt and Oracle reports as a user interface.

    We already integrate across technologies today, with DHTML/Javascript on the client, Java on the server and SQL in the database.

    The Agile approach is to build for today, refactor for tomorrow. I can forsee no circumstance where this approach is not adequate. Why speculatively invest in a future that may never materialise? The chances are that the guess you make today will be wrong. This is common mistake that leads to over-engineering.

    It is possible to create an enterprise wide architecture that avoids speculative over-engineering. A lot of top corporations do this today, with Java/J2EE for front end service integration and delivery, Tuxedo (or similar) as the enterprise messaging backbone, and C/C++ in the back-end. In such an architecture, I see no reason why Java/J2EE (or .NET) could not easily be replaced with something like Ruby at the front end. The advantage of this functional splits is that business services can be delivered quickly in the front end. If over time these services need to become more robust or more performant, or require true enterprise presence then they can be migrated (refactored) to the back-end (incidently there is also a good argument for replacing C/C++ in the back-end with say Java over time, but of course that may mean re-writing a lot of legacy code that already works, so why do it?).

    Thinking out of the (vendor) box.

    Paul.
    I totally agree with your point on technical merits. The problem is try to convince your network and server team to support this heterogenous environment and I understand their concerns. Maybe big corporations like Google can do it but unfortunately integration and SOA still have a long way to go in my opinion before we can really pick and choose the right tool for the job in any language although I would like to see it happens. This is why I think supporting other language in the VM is so important.
  315. Re: Boring[ Go to top ]

    We already integrate across technologies today, with DHTML/Javascript on the client, Java on the server and SQL in the database.
    The advantage of some Java-based approaches is that you can integrate across technologies such as these without having to use them much. There are Java solutions that generate almost all of of the Javascript and SQL for you.
    In such an architecture, I see no reason why Java/J2EE (or .NET) could not easily be replaced with something like Ruby at the front end.
    Yes, but what is the 'something like Ruby' you would use? Ruby isn't really suitable as it lacks features such as internationalisation. What would you use?
    The advantage of this functional splits is that business services can be delivered quickly in the front end. If over time these services need to become more robust or more performant, or require true enterprise presence then they can be migrated (refactored) to the back-end
    This can cause a lot of issues - there are questions about how the functions should be split - make a wrong decision and you can end up with a lot of migration work if you used mixed languages. This can be very messy in my experience.
  316. Hi Steve, I tend to find your responses pretty defensive. History has shown that technology moves on and the only constant is change. We have lived with heterogeneous "enterprise" environments from the beginning. As new technologies comes on stream, old ones fade very slowly, resulting in a mix of legacy systems, which is common in most large corporations. Cobol, CICS, C, Unix, C++, DCE, RPC ,CORBA, RMI, Tuxedo, Java, C#, VB, .NET etc will all be with us for a long time to come, possibly joined by new comers like Ruby and Python. This is just how things are:
    The advantage of some Java-based approaches is that you can integrate across technologies such as these without having to use them much. There are Java solutions that generate almost all of the Javascript and SQL for you.
    So? If I have to write just one line of XML, or JavaScript or SQL it is no longer a Java only solution. I will have to integrate with these non-Java technologies (using XML parsers, JDBC drivers etc).
    Yes, but what is the 'something like Ruby' you would use? Ruby isn't really suitable as it lacks features such as internationalisation. What would you use?
    Who said internationalisation was a requirement? And even if it was, what is stopping me implementing it in Ruby? (even if I have to write it all from scratch myself).
    This can cause a lot of issues - there are questions about how the functions should be split - make a wrong decision and you can end up with a lot of migration work if you used mixed languages. This can be very messy in my experience.
    Most truly enterprise wide applications are heterogeneous, if this makes you uncomfortable then move to another planet. The reality is that Java/J2EE is just a small part of the enterprise. True enterprise wide applications are all about integration, or what has become known as EAI. By the time you get around to re-writing all of the ‘legacy’ code in your enterprise in Java/JDO/JSF, something better will have turned up and you'll have to start all over again, kind of like painting the forth bridge :^). Are you serious or are you just playing devils advocate? Paul.
  317. Hi Steve,

    I tend to find your responses pretty defensive.
    No, they are based on harsh experience.
    History has shown that technology moves on and the only constant is change. We have lived with heterogeneous "enterprise" environments from the beginning. As new technologies comes on stream, old ones fade very slowly, resulting in a mix of legacy systems, which is common in most large corporations.

    Cobol, CICS, C, Unix, C++, DCE, RPC ,CORBA, RMI, Tuxedo, Java, C#, VB, .NET etc will all be with us for a long time to come, possibly joined by new comers like Ruby and Python. This is just how things are:
    But only at a certain scale of development. This thread is about "small- to mid-scale applications". What about development that isn't "enterprise" - the moderate-sized website, the Swing client-side application, the mobile device application. I see a tremendous potential for code reuse (this is not the anti-agile writing code in advance as libraries for re-use, but simply knowing that much code you write can in principle work in a variety of environments). You see, I have seen a phenomenal amount of code waste in various situations. Code has been developed in the latest fashionable language. And then had to be re-written, and re-written again as new requirements and platforms appeared, whereas if the developers had stuck to a more widespread and less fashionable language (in those days, Pascal or C++) then things could have been far easier. These days, Java is the new C++. If I write code in Java I know that I can in principle re-use much of that code in a variety of situations - mobile devices, websites, client-side apps etc.
    The advantage of some Java-based approaches is that you can integrate across technologies such as these without having to use them much. There are Java solutions that generate almost all of the Javascript and SQL for you.
    So? If I have to write just one line of XML, or JavaScript or SQL it is no longer a Java only solution.
    That is not the point. Just because a Java solution can't do everything is not a reason to abandon it. If something can do most of the work for you, and do it well, it makes sense to use it.
    I will have to integrate with these non-Java technologies (using XML parsers, JDBC drivers etc).
    No, you don't. You don't need to use an XML parser to work with the XML in JSF or JDO. You don't need to use a JDBC driver yourself to integrate with native SQL with JDO.
    Yes, but what is the 'something like Ruby' you would use? Ruby isn't really suitable as it lacks features such as internationalisation. What would you use?


    Who said internationalisation was a requirement?
    For any serious web development the option of internationalisation should be a requirement.
    And even if it was, what is stopping me implementing it in Ruby? (even if I have to write it all from scratch myself).
    Why on Earth would you want to write it from scratch? Use a language like Java that gives it for free.
    This can cause a lot of issues - there are questions about how the functions should be split - make a wrong decision and you can end up with a lot of migration work if you used mixed languages. This can be very messy in my experience.


    Most truly enterprise wide applications are heterogeneous, if this makes you uncomfortable then move to another planet.
    Just because there is already this heterogeneity, this is no excuse for adding extra layers of it.
    By the time you get around to re-writing all of the ‘legacy’ code in your enterprise in Java/JDO/JSF, something better will have turned up and you'll have to start all over again, kind of like painting the forth bridge :^).
    I wasn't talking about re-writing legacy code.
    Are you serious or are you just playing devils advocate?

    Paul.
    I am serious.
  318. Are you serious or are you just playing devils advocate?

    Paul.


    I am serious.
    Well if you are serious, you have a very narrow view of IT and software technology in general. One size doesn't fit all, and we will always have choices. The skill is in making the right choice. This use to be known as technology selection which should occur after you've done some analysis of your business problem. You seem to want to select your techology before looking into the specifics of the problem at hand, way before. In fact you are suggesting that all new enterprise development should occur in Java exclusively, not just in your organisation, but everywhere irrespective of the requirements. I agree that there are barriers between languages, but these barriers in the most part are artificial IMO. For instance what is there stopping all so called OO languages sharing a common Object Model? With objects that can be transfered across a variety of languages? In fact this kind of stuff is already possible within the JVM today (to some degree). I am not suggesting adding complexity for it's own sake, but If I can implement a simple CRUD Web App in a fraction of the time today in RoR and later add enterprise wide services by integrating it with an available Java/C++/C#/PickAnyLanguage service tommorrow when needed, then to me the business case in favor of RoR for the front end is clear. Paul.
  319. Are you serious or are you just playing devils advocate?

    Paul.


    I am serious.


    Well if you are serious, you have a very narrow view of IT and software technology in general.
    As someone who has used a very wide range of languages and techniques over nearly 30 years, I disagree. I believe I have the views I have because I have a very wide view of software technology, and have seen so much go wrong in so many areas :)
    One size doesn't fit all, and we will always have choices. The skill is in making the right choice. This use to be known as technology selection which should occur after you've done some analysis of your business problem.

    You seem to want to select your techology before looking into the specifics of the problem at hand, way before. In fact you are suggesting that all new enterprise development should occur in Java exclusively, not just in your organisation, but everywhere irrespective of the requirements.
    No, I have never said that. What I am trying to avoid is the idea of 'throw away' code. The idea that something can be thrown together now in Ruby, leading to major problems in say 5 years when the demand on the application has increased by an order of magnitude and a re-write is necessary. I have seen this kind of thing happen so often. When there is a general purpose language that is fast to develop with and has the power to deal with future increases in demand, complexity and range of use, then any substantial development that does not use that language should have to be justified. I am not saying it is wrong not to use Java, but that, for me at least, there have to be very good reasons not to use it for any substantial development work.
    I agree that there are barriers between languages, but these barriers in the most part are artificial IMO.
    Having had to deal with these for years, I disagree. (I had to do some Smalltalk to C interfacing years ago, and it was a real struggle).
    For instance what is there stopping all so called OO languages sharing a common Object Model? With objects that can be transfered across a variety of languages? In fact this kind of stuff is already possible within the JVM today (to some degree).
    Exactly - to some degree. My attitute towards mixed-language development will change when you can (for example) seamlessly use Java from, say, JRuby and use JRuby classes from Java (directly, not via BSF).


    I am not suggesting adding complexity for it's own sake, but If I can implement a simple CRUD Web App in a fraction of the time today in RoR and later add enterprise wide services by integrating it with an available Java/C++/C#/PickAnyLanguage service tommorrow when needed, then to me the business case in favor of RoR for the front end is clear.


    Paul.
    RoR lacks certain features that mean it is potentially disqualified for a range of applications. International websites for one. Those that need may need some high-performance functionality, such as image transformation or numerics.... the question is, when will a simple CRUD web app potentially change into something more complex? Is this rare enough that you can risk using tools suited only for simple CRUD web apps? My judgement is that this is not rare enough. I have seen all this before. Years ago, developers were saying the same thing about Visual Basic... 'But I can put up this neat form and I can deal with all the enterprise stuff later'... Many of us are still dealing with the consequences. Of course, one of the fastest ways to develop a simple CRUD web app is actually in Java, with Studio Creator (a Visual Basic approach, but with the option of real J2EE muscle when required). As I said above, my views are likely to change when the JVM becomes a friendlier platform for multi-language use - then it would be possible to migrate code between different popular languages gradually and seamlessly as needs change. Next year, I may have different opionions!
  320. Hi Steve, I can see this will run and run. I'm talking from experience too. I've done this using Java/Tuxedo/C++ and the world didn't cave in. In fact it worked very well and such an heterogeneous architecture added considerable business benefits (these were at companies that seriously pushed their IT infrastruture: T-Mobile and DHL). You seem to be confusing poor code with the language it's written in. I could argue that depending on your metric, the code quality in Java is likely to be worst than the code quality in Ruby. I've seen plenty of supposedly OO code in Java that was actually procedural (long methods, case statements, inappropriate use of inheritance,etc) to last me a life time. Now if those Java boys had replaced the case statement with closures then things may have been different :^).
    No, I have never said that. What I am trying to avoid is the idea of 'throw away' code.
    The quality of the code comes down to the developer. If it is good clean code it will last a long time, through refactoring, if it is bad code then entropy will quickly kick-in and you will have to through it away. RoR lacks certain features that mean it is potentially disqualified for a range of applications. Java lacks certain features that mean it is potentially disqualified for a range of applications... :^) I could say the same of any language. You are comfortable sticking with Java and that's fine, but there are alternatives and if approached properly there are business benefits to be had. I know we won't agree. See you at the next discussion. Cheers, Paul.
  321. Hi Steve,

    I can see this will run and run.
    I expect so :)
    You seem to be confusing poor code with the language it's written in. I could argue that depending on your metric, the code quality in Java is likely to be worst than the code quality in Ruby. I've seen plenty of supposedly OO code in Java that was actually procedural (long methods, case statements, inappropriate use of inheritance,etc) to last me a life time. Now if those Java boys had replaced the case statement with closures then things may have been different :^).
    No, I am talking about something completely different. (see below). I am talking basically about language qualities, not code quality.
    No, I have never said that. What I am trying to avoid is the idea of 'throw away' code.


    The quality of the code comes down to the developer. If it is good clean code it will last a long time, through refactoring, if it is bad code then entropy will quickly kick-in and you will have to through it away.
    Yes, but there is a big leap between the quality of the code and what the implementation of a language is capable of. I think you are confusing the two things. I can write wonderful quality code in VB6, but it won't run on Linux no matter how good my code. It is pointless to try and develop reasonably high-performance numerical algorithms in Ruby no matter how elegant the coding is. My approach (which I am sure many will disagree with) is roughly this... you can never be sure where your code will end up; what platform, or at what scale of use. By developing my ReallyUsefulStringFunctions class in Java, I am pretty much guaranteed that I can use that class on a large clustered web app, a client-side app, on a mobile device app... Sure, there are some situations that seem pretty fixed. I write some business logic using JDO interfacing to Oracle. Or is this fixed? Supposing someone wanted to run this code on a small subset of the data on a portable device; perhaps an embedded database, or an XML version of some of the data. With Java+JDO that can be done. I am a huge believer in portability. Portability across operating systems, portability across GUIs, portability across persistence mechanisms - and - portability of code and libraries across a range of potential uses.
    RoR lacks certain features that mean it is potentially disqualified for a range of applications.


    Java lacks certain features that mean it is potentially disqualified for a range of applications... :^)

    I could say the same of any language.
    Yes, but Java is, by any standards a general purpose language, and has a proven record in a very wide range of uses, where languages like Ruby are never likely to go. In this respect, all languages aren't equal.
    You are comfortable sticking with Java and that's fine, but there are alternatives and if approached properly there are business benefits to be had.
    Actually, I don't stick entirely with Java. I use a wide range of languages depending on the circumstances - Python for system scripting, for example, or (for various reasons) JRuby and Groovy for financial code scripting. But for general development - yes, I use Java for that. This is not a matter of being 'comfortable'. This is a carefully weighed decision.
    I know we won't agree. See you at the next discussion.

    Cheers,

    Paul.
    I look forward to it.
  322. I think the problem described boils down to vendor support. The choices are: - Microsoft .Net - No vendor + some form of Java - Vendor + some form of Java What people in organizations might want to do is promote a particular flavor of Java. For example: - IBM's stack of Java products - Oracle's stack of Java products - Sun's stack of Java products - JBoss's stack of Java products (these are just what come to mind.. don't flame me if this list is incomplete) What that does is limit the amount of choices your company has to make, while at the same time putting the possibility of support behind it. I don't really follow my own advice on this.. As a result I often wonder if the choice I made was the correct one. The choice isn't between Java and .Net. It's between some configuration of Java tools vs the MS tools.
  323. The begging of this article make me really angry. I understand manager who think that the rapid developed application with de-facto none decisions in technology is right thing for "workers" in her team. OK, but there are a lot of cases in which this easiness is harmful. What if there is critical bug discovered, or hidden "feature". And unfortunately it isn't rare thing in MS products. I like freedom in choice. There isn't right solution for every case. I prefer mixtures of optimal pieces to solve the problem. I prefer chance to change not suitable piece for better one. I like freedom which Java brings. And there is other "political" issue of .NET platform. If anybody will use it, why can't MS charge money under other EULA statement? I like liberty and chance to make decisions out of borders of any company aims.
  324. Sound like choices are bad[ Go to top ]

    And single solution without choice is better?
  325. Software Factories?[ Go to top ]

    Microsoft is preparing a new approach for software development "Software Factories". What's the future of Java?.