Posted By: Abhinav Taneja on March 7, 2001
I am working with my company's IT Division to decide the future direction of the Architecture for our company.
There is a debate between choosing between J2EE and .NET
Any thoughts on these lines would be helpful. Please answer keeping following issues in mind.
1) Which architecture is more robust for applications which require extensive search mechanisms and documents sharing and transfer and collaboration ?
2) Which options will reduce time to market and cost to market or develop and cost to maintain applications ?
3) Which architecture will useful for future flexibility of moving towards an ASP ?
4) Does size of IT shop and in house vs. out house development make a difference of what you choose ?
Thanks
Abhi
22 replies in this thread Reply
J2EE vs .NET
Posted By: William LaForest on March 8, 2001 in response to this message.
I have spent a lot of time working with both technologies and feel relatively unbiased.
I feel as though both technologies can satisfy your need for facilities which will provide robust support for document collaboration and searching.
The second consideration you raise is difficult to address without a fundamental understanding of your organization. If your company already has a slant one direction or another then re-education and staffing issues may become an important issue in determining time-to-market and development expense.
All things being equal there are a few factors to consider. If you choose to go J2EE then you must factor in time and cost in evaluating what implementation is going to be best for you; a small overhead but one that shouldn't be overlooked. I have found from the last three middleware projects I have been on that J2EE tends to incur more time costs from staff education due to the separation of specification and implementation. The developers must have understanding of both the J2EE API and the underlying implementation that you end up using. This is not entirely obviated in the Microsoft platform but information seems to be more concentrated. If you are able to come up with a full staff of seasoned developers in your chosen platform it won't matter... good luck!
I have found that, in general, speed to market has been faster in the Microsoft world due to the simplicity of some of the development tools and the use of VB. The more complex the system, however, the better J2EE becomes. VB and COM will become overburdened by their simplicity and C++ COM is more time consuming then J2EE to begin with. Cost of maintenance is almost always in the favour of J2EE for reasons I will touch on in response to your third question.
One thing I feel positive about: J2EE is much more successful in promoting code re-use. When I say code re-use I'm not referring to (in Microsoft parlance) component aggregation and extension. I'm talking about old fashion OO fundamentals. Microsoft is always touting binary (component) re-use and this is obviously good practice. I have read a myriad of articles and books where Microsoftonians say that traditional OO code re-use just never worked out that well; they obviously haven't implemented to many projects or architectures using a quality OO language such as SmallTalk or Java! I have found that J2EE projects almost always have a healthy share of both component reuse AND general OO reuse. Not every piece of code you write is going to end up as a component/EJB. My current project has a wonderful framework of Java classes that is constantly being extended through normal OO inheritance. Obviously this is possible in the Microsoft world if you choose the right language and are careful to enforce the right project policies but this happens far less frequently than in the Java world where it just seems to occur more naturally. For this reason alone I prefer J2EE for companies that are using an ASP model and require great flexibility.
For your fourth question I think it is pretty clear that J2EE lends itself to heterogeneous environments much more than Microsoft's technologies. This can help if you need to out-source pieces of development to third parties.
Well I've rambled on long enough and I'm sure there are a bazillion points I failed to bring up. Hopefully this helped some!
-Will
0 replies in this thread Reply
J2EE vs .NET
Posted By: Bernhard Messerer on March 9, 2001 in response to this message.
I guess there is not enough time to point out all differences and points, and I think I don't have the knowledge to do this.
4) Yes, when your size is big your option currently is only J2EE I guess... ever saw a big company settling on Win32 Servers?
Well, I now just wanted to point out some general points:
*) Many vendors (Sun, IBM, Oracle, Borland...) have always tried to get something they can fight MS with. And now they have the chance of doing this with J2EE. Additionally billions of dollars have been invested in J2EE... Do you think they'll just throw this away in favor of .NET? So I guess vendor participation will be better.
*) If you are unhappy with MS .NET implementation (bugs ec., I cannot say that MS delivers bug-free software) what will you do? The same thing as now, wait for the next release/SP. In contrast, you somewhat freely choose your J2EE vendor. If coding carefully you can often switch within some hours (we even had applications being transferred with some clicks).
*) .NET is currently not available. Big and small companies need enterprise solutions _now_, so they buy J2EE solutions, and buy application servers. I think this will be the same kind of situation (but much "worse") as with databases today: if they have Oracle they'll refuse to buy DB/2, although they are quite similar, compared to .NET vs. J2EE. So I guess companies will refuse to buy your products if they are .NET, who wants to maintain 2 complete architectures? However, the same can happen to you with J2EE: If one customer say "WebSphere and nothing else" you may have no chance because you always used BEA.
Alltogether I think that MS is too late at the moment, their architecture is two years behind and needs some time of real-world use to mature. I also think J2EE has gained too much industry momentum for .NET to have a chance. Consider that, at the moment, you have no option other than J2EE for server side programs (besides plain Java)... we have a monopoly like MSs in this area.
However, I also agree with Gartner Group, who say that .NET will be adopted by small shops/vendors while J2EE will rule in the big shops, but the small ones with .NET will cease with time. Again consider: Here (and with Linux) is the chance of the industry to beat MS. Ever wondered why Java and J2EE were adopted so fast (well, they are good, but many things were good, CP/M was, GEM was, Netscape was...)?
just my 2 cents
Messi
2 replies in this thread Reply
J2EE vs .NET
Posted By: Lee Fuller on March 9, 2001 in response to this message.
Good reasonably unbiased comments. It's good to see less of the religious positions that some people take (unless you're independently wealthy, most of us are in this to get paid and support the kids :-).
I would just add the following point about maturity of the technologies.
.Net is based on COM+, which is based on COM/MTS. This means that many of the technologies are deployed to the mass market, given they are a tightly integrated part of the operating system. Yes, .Net is "NotYet" and is not likely to be until later this year, but when it arrives it will have the advantage of being a mass market release and like the CORBA/COM competition, is likely to be the most widespread use of these technologies. So the "2 years behind" approach is naive, most of the base .Net technologies were in place with Windows 2000 (COM+, MSMQ, queued components, IIS5/ASP+, SQL2000, now BizTalk for EAI) - .Net is a neat layer of additional services which makes life even more interesting. The same component-orientated infrastructure that is running the Windows 2000 operating system, is also used to run the applications (where as OS's like Un*x, given their 70's heritage, can't be re-engineered to be component based operating systems and thus this support is always vertical and not as tightly integrated).
So, no matter which set of technologies are "better", the real challenge to J2EE vendors will be the mass-market coverage of the Microsoft platforms. Un*x platforms still have a big edge on single box performance, but are getting squeezed below from clustered Windows 2000 deployments (see www.tpc.org) and above from mainframes who are interested in getting more into these e-times.
Lee.
4 replies in this thread Reply
J2EE vs .NET
Posted By: Damian Roskill on March 9, 2001 in response to this message.
I guess I would agree with most of the points made here. Kuodos to everyone for not makeing this a religious war! Some thoughts:
Main Points
--------------------------
- Size of project definitely makes a difference. EJB is a lot of work for small projects (also can be very expensive). For these, MS products make a lot of sense (as do JSP/servlet products). EJB is far, far better for larger, more complex, more "true application" work. I totally agree with the comments about code reuse and the benefit to an ASP model.
- J2EE is obviously the choice if you are working across multiple platforms.
- .NET supports a large number of languages. If you already have developers who know C++, you may want to continue to develop in that rather than change languages. .NET is the winner in this area.
- Microsoft definitely has a strong edge in the general developer community, with a large number of people who already use and know the basic tools that will be extended for .NET (with the acknowledgement that many will have to update their skills to use the .NET platform). As such, it will probably be easier to recruit a development team at a lower cost. This is, however, changing all the time. Microsoft just does a fantastic job of wooing developers to all kinds of trade shows.
- Microsoft has excellent 3rd party application support. This is true in terms of development tools and add-on products. EJB has, in my opinion, just come of age with the J2EE platform and development tools like TogetherJ that start to create a good environment for the developer.
- Microsoft's .NET is not here, but you can never underestimate the power of Microsoft to charge back (ala taking out Netscape). With over $100 billion in the bank, they can pour money into the project.
Secondary Points
---------------------
- The XML support in .NET, in my opinion, is better than the support in J2EE. J2EE is rapidly catching up, but MS has definitely gotten into the web services/SOAP model and the tools are pretty impressive.
- J2EE clearly has a strong head of steam behind it.
- .NET is mostly unproven in large scale deployments. I say mostly because SQL2000 is being used in large deployments quite successfully.
- 3rd party software vendors (companies like Broadvision, etc.) have already shown that they will probably support both .NET and J2EE. I think this will continue.
All that being said about Microsoft, I'm spending a lot of time right now on J2EE development because I think that long term it's going to have a huge impact on development. I think we are heading to more of a programming assembly approach with J2EE and the web services model associated with .NET.
I know it's a little silly, but right now I'm playing around with J2EE products under Win2k. Why? I like a lot of the stuff of Win2k, but I want the flexibility that J2EE provides.
That's why I'm excited mostly about SOAP and web services because interopt becomes a lot easier with these technologies.
Anyway, just my 2 cents. I'm not a religious zeolot on either side...I happen to think both platforms are pretty darn good and hold a large amount of promise.
Damian
3 replies in this thread Reply
J2EE vs .NET
Posted By: Ganesh Prasad on March 12, 2001 in response to this message.
I have a slightly different take on J2EE vs. .NET.
Component architectures are a means to an end. The end is a scalable, maintainable application that is also quick to develop and deploy. When looked at this way, there are actually 3 alternatives.
1. "LAMP", or Linux-Apache-MySQL/PostgreSQL-PHP (good for 80-90% of web applications, the low to mid-range)
2. .NET (not clear what the range will be, but definitely something for existing Microsoft shops to consider)
3. J2EE (IMHO, overkill for all but the most complex applications)
Many companies will stay with Microsoft, but there is a basic contradiction in .NET. If it is open, then you should be able to bypass Microsoft and get your products from any vendor or even Open Source project. It's doubtful if Microsoft will let that happen. On the other hand, if .NET is not open, then you should be extremely wary of going down that path, or you'll end up getting locked in.
I think the low cost and extremely fast time-to-market that PHP offers will offset any advantages that a full-fledged component architecture may have. Implementors are generally not religious. They may like the elegance of an architecture, but if they get a 2- to 3-fold improvement in productivity with a tool like PHP, that's not something they can sneeze at. I'm a Java programmer myself and I should be expected to support J2EE against all comers, but I've been pleasantly surprised by the productivity advantages of PHP. For small to medium applications, you can get something running much faster with PHP than with JSP (my experience).
So in my view, your company should also evaluate the PHP option in addition to .NET and J2EE. True, it doesn't pretend to be a component architecture like the other two, but the productivity you get should be experienced at least once. Who doesn't want to improve time-to-market?
Regards,
Ganesh Prasad
3 replies in this thread Reply
J2EE vs .NET
Posted By: Kapil Israni on March 12, 2001 in response to this message.
This is indeed turning out to be a healthy discussion. thought about chiipin in.
Well for me the most important factor for picking a development platform is code maintainability and extensibility and obviously scalability and stuff come next. i have devoted considerable amount of time developing for both Microsoft platform and now the Java enterprise platform. and the latter definitely has the edge in that respect. i think microsoft is a great platform for writing applications real quick but if you have an application which consistently changes then Java as a language is the one to pick. in terms of performance i think microsoft can scale as well as J2EE platform with the inroduction of windows clustering services etc.
i know someone mentioned up there that .NET is based on COM+. this is in total contrast to what i know and have read. and to me .NET is totally a new platform for writin your components. in fact lately read a Don Box article(COM guru) and the bottom line of that article was .Net is not COM at all. its entirely different with the introduction of CLR platform and programmers are encouraged to program and leverage the benefit of CLR. though microsoft is not stopping us to write COM libraries but surely they wont encourage you to code them. also .Net is being talked bout the platform for Web Services. What is .Net? .Net is all about Set of languages which get compiled to one comman binary language and then run within the CLR. and then u have the big piece XML/SOAP/UDDI which binds all these languages for RPC communication. also you also have ADO.NET which can import n export RDBMS data in XML format.
I really dont know how can all these things can make .Net the platform for Web services. in fact java enterprise has all these things. the big binding piece namely XML/SOAP is all about how you implement it in your applications.
i know we are all talkin about web service but no one knows how they look and how will they work and collobrate together. so its to early pick one platform as the one platform for web services.
though i can say definitely say one thing seeing the kinda of work i am doin at the moment, J2EE clearly is "the enterprise platform" for now and i m eagerly awaiting to see what .Net has in store for the enterprise.
kapil
0 replies in this thread Reply
J2EE vs .NET
Posted By: Bernhard Messerer on March 12, 2001 in response to this message.
First: I'm always trying to be unbiased, simply because my job is to develop good applications... not to evangelize. Its true, I favor J2EE... but I think I have good reasons to do so, and if I see .NET is cooler I'll switch.
That .NET is based on components already there is true... BUT: The best "component" MS produces is (IMO) MS SQL Server. COM+, MTS etc. cannot really compete with products in the J2EE area; simply because J2EE is open I think: Everyone can integrate their products, the things they know best, like IBM MQSeries, BEA Tuxedo, Inprise VisiBroker... specialized products which do their job very well, integrated all together. This is also the case with SQL Server: With this database I think MS has created something that really stands out: as easy to manage as Sybase ASA and as powerful as Oracle and DB/2 together. But the really nice thing is "Using it with J2EE?" No problem.
I know that most products will also be able to be integrated into MSs platform (and in fact they partially are), but I want to see this before I believe it (this is mainly again "J2EE is here now")).
I also wanted to point out that the "multi language support" is IMO something only few companies will use. Simply because yes, it is cheao to get a development team, because you have the know how there (well, not really, see below): You make up a team of 1 COBOL, 2 VB, 2 C++, 1 C# and 1 Eiffel programmer. Cheap to develop the application. But who will maintain it? The COBOL programmer may leave... getting another one? Oops, quite expensive.
In general, I think companies will choose to switch language instead of going into this maintainance nightmare. Because learning another language is quite "easy", the fundamentals are normally the same. And Microsoft will also enforce this by preferring C# to develop for .NET, the same way C++ became favored above C (although you could still use it).
Well, and now to the "you already have the know how"... I guess e.g. a VB programmer will have a hard time learning .NET, because it is a different world. The problem is: Learning a language takes you a week, even a complex one like C++, if you are familiar with the concepts (VB programmers will have to switch to OO, so they don't know the concepts); From C++ to Java is 2-5 days. But try to learn MFC, Swing, OWL, VCL, Qt, STL, EJB, JDBC and so on (... .NET). This will take you a lot longer. I think what counts is the _framework_ you have to learn. And the framework, your class libraries, are completely different with .NET compared to Win32, MTS... So I guess the time it takes you to switch to Java/J2EE will be equal to switch to .NET (both from Win32, ODBC, COM+...).
However, one thing I really like about .NET: The WebForms. This is simply great (but there is a Swing-like library that does the same for the Web).
cu and hope to recieve many nice comments
Messi
3 replies in this thread Reply
J2EE vs .NET
Posted By: Damian Roskill on March 13, 2001 in response to this message.
What is the Swing library you're referring to? I'd love to take a look at it...
Thanks,
Damian
1 replies in this thread Reply
J2EE vs .NET
Posted By: Bernhard Messerer on March 14, 2001 in response to this message.
Swing is a library for GUI widgets included in JDK 1.2 and above (spearately available for 1.1); It is really nice to use and far superior to AWT.
But I think you know, guess you'd like to know of the "swing-like" library for Web-Apps (like WebForms); There are two of them, SPFC which is member of the Jakarta (Apache) project and thus open source(http://jakarta.apache.org/cvsweb/index.cgi/java-spfc/), but not much to see yet, and Swinglet (www.swinglet.com) which is commercial.
I have not used any of it.
Hope this helps a bit
Messi
2 replies in this thread Reply
J2EE vs .NET
Posted By: Gal Binyamini on March 15, 2001 in response to this message.
Hi.
Bernhard mentioned a report by the Gartner Group where it analyzes the future of J2EE/.NET. I would very much like to see the specific analysis (although Bernhard already mentioned the conclusion).
Does anyone know of an online copy of that report? If you do, please post the address here or email me at nerlin@inter.net.il.
Thanks in advance.
Gal
0 replies in this thread Reply
J2EE vs .NET
Posted By: Basil Tchurilov on March 16, 2001 in response to this message.
>> .Net is based on COM+, which is based on COM/MTS.
Bosh!!!
Lee, I think you better now what are you talking about before posting here such a statement.
Well, I had worked with MS COM/MTS and COM+ before I moved to J2EE, and here is my comment on it:
.Net is completely different and is not based on COM. Even people from Microsoft claim it. That means that .Net isn't mature enough to consider it as J2EE competitor, and what is more it hasn't been realesed yet at all and is still in beta. I think .Net will be mature enough only when a few years will pass, and MS will need really BIG investments to make .Net mature.
IMHO it's no good that MS suddenly dropped COM and created completely new middleware platform without leveraging COM. There are already enough component technologies and the world doesn't need a new one. In the beginning MS with COM was 2 years behind CORBA and (in spite of the fact that COM+ was near to catch up with it(CORBA, not J2EE)) I think, having minimum 3 years of gap in the moment, MS's .Net came too late...
>> Un*x platforms still have a big edge on single box performance,
>> but are getting squeezed below from clustered Windows 2000 deployments
>> (see www.tpc.org)
TPC is not a gauge! In fact some vendors (try to guess who) are even changing their DBMS's kernel appropriately to match TPC specification, while the specification itself is too simple and straightforward to reflect real business applications.(Do you really think that W2K/COM+/SQL Server will be 10 times faster than AS400/Tuxedo/DB2 in a REAL scenario?)
>>.NET supports a large number of languages.
>>.NET is the winner in this area.
And what about CORBA? It supports really all languages including Java and has almost 10 years of maturity.
Microsoft held a presentation is our University, and the speaker said that the coolest advantage that you will have when using .Net "multilanguaging" feature is that "you can have VB class that you can inherit in your C# class for example" =)))(Just imagine such a nightmare)
All the time during this presentation I asked myself a question: "Why Microsoft couldn't just buy Sun's licences? It could be much more cheaper than create and propagate it's own."
2 replies in this thread Reply
J2EE vs .NET
Posted By: Justin Grant on March 16, 2001 in response to this message.
.NET is not based on COM/DCOM/COM+, it is a completely new model very different from these but suspectly similar to the Java in some ways (e.g. namespaces for packages).
It's obvious why M$ is moving away from COM, DLL hell.
In large applications, having x number of different versions of the same component becomes very tedious to manage.
An important point to consider is that .NET is mostly vapour ware and hoping it will be as successfull as IE is not realistic as IE is only a desktop application while .NET is supposed to be an enterprise devlopment platform.
my 0.02c anyway...
0 replies in this thread Reply
J2EE vs .NET
Posted By: Ron Mulheron on March 18, 2001 in response to this message.
It really depends on your timeframe for implementation of the chosen architecture, and your chosen deployment platform. At the moment, J2EE is maturing and as such its uptake at the moment is huge; it is also (to an extent) portable across platforms. .NET is all vapourware and marketing hype at the moment, and your deployment platform is limited to Windows. An easy decision, I would have thought ...
0 replies in this thread Reply
J2EE vs .NET
Posted By: Scott Mutchler on March 19, 2001 in response to this message.
.Net will definately allow you to get to market much sooner with a smaller learning curge (for much less $) than J2EE. M$ has always had the best integrated, most productive IDEs. Creating an application for MTS is as simple as dragging and dropping a DLL onto a window (.Net will be even simpler). BEA Weblogic 6.0, on the other hand, makes you edit XML files by hand and build JAR/EAR files using command line utilities. While this is great once you have got it all working, it really slows down your initial development effort. Its hard to believe that a $16K/processor piece of software is so "user-angry".
That being said M$ products tend to make simple projects easier and difficult projects more difficult. J2EE makes complex applications much easier to implement. M$ makes the first 90% easy but the last 10% can be incredibly difficult. This is mostly because of their closed nature. .Net is more "open" than COM but you still can't look at the source code! I don't know how may times I got to a problem with a M$ product and hit a brick wall.
.Net is a big step forward. It's simpler than J2EE but I prefer J2EE for large complex projects. I just wish the App Server market would mature more quicly and give a user friendly product that has the high availability/scalability of Weblogic.
1 replies in this thread Reply
J2EE vs .NET - We need better UI
Posted By: Oscar Marquez on March 19, 2001 in response to this message.
We need better UI
I don't know why companies like Oracle, BEA, iPlanet can't make a good UI tool to manage and deploy Apps in their App Servers.
It's weird but I have been using J2EE RI and it has a great UI, the best that I have seen to work with App Server, maybe javasoft could make it an open deploy tool source code to be followed by the others App Server in the market.
I prefer to use an application to do my pointless work (creating the XML deployment descriptor, packing jar, Mapping fields, etc) and work more in the code.
Regards.
1 replies in this thread Reply
J2EE vs .NET
Posted By: Lee Fuller on March 19, 2001 in response to this message.
Ho hum. Enter the religious comments. Shame, coz the previous posts were so mature. :-(
Anyway, just to quickly give you something to think about with regard to your post. Yes, you are right that Net is a new set of technologies, but the point I was making (which you chose to miss) is that the underlying layers are still COM+ (because Windows 2000 is fundamentally so - for example, MSMQ, ActiveDirectory, Index Server, COM+ transactions - yes, still underneath there). And yes, CORBA is more advanced than COM+, I think no-one can argue that - the point is that of mass market distribution and that is how MS have managed to swamp often better options.
Drink less coffee and _try_ to be a bit more agnostic!
Lee.
0 replies in this thread Reply
J2EE vs .NET
Posted By: Reha Elci on March 20, 2001 in response to this message.
Your points about the framework makes a lot of sense. But it is also important whether the 'framework' can take you from A-Z consistently. While j2ee is a framework, it also comes with a 'native' language for that framework. This means that regardless of how small or big your projects are, if you are following good practices, you will want to start with UML, choose an OO language that reflect well the domain models, use standard patterns for your architecture, and find a wealth of implementation that follows those standards. From that perspective, j2ee is a one-stop
shopping center.
In the MS world, my impression is that this is not there.
There is a rich set of classes with the C++ world, but if you started that way, you can't end up with .asp which is closer to the VB world.
While entry into the j2ee framework may seem high, the completeness and the consistency of the framework is a significant advantage when you are there.
0 replies in this thread Reply
J2EE vs .NET
Posted By: Bill Pfeiffer on March 21, 2001 in response to this message.
Since we've heard from the unbiased folks on this subject, I thought I throw my biased $.02 in.
First, my biases:
I am biased towards type safe languages that promote good programming practices and maintainable code (I feel C# and java both meet this criteria, C++ and VB do not)
I am biased toward IDE/Tools that allow me to develop fast, native l&f type apps for my user's OS of choice and that means Windows. I haven't talked with 1 customer (insurance industry) who uses anything else.
I am biased toward whatever architecture will allow me to reach my target audience in the quickest most flexable manner. This means distributed via the internet overwhelmingly via http.
Next my j2ee/.net take:
I am currently heavily invested in the application of the j2ee technologies. The architecture is good, the tools suck. My productivity in the tools sucks. I'm currently paying the price for choosing SilverStream (heavy indeed), but I don't see the other app server / tools combinations being that much better. There is a reason that the java programmers keep falling back on emacs/textpad. What choice do they have. Really.
I saw the architecture, ide, SOAP web services in the visual studio .net demo and for a change I got excited about the tools. An IDE that will let me write code, compile quickly and debug, within the SAME tool, without going to lunch every 10 minutes for 5 minutes at a clip. (Excuse me while I restart my SilverStream server and ide for the 10th time today...)
On top of that, when I am ready, I can deploy my web services in a manner that will allow other VS.net developers to call, see, and code to (with intellesense) my web services, all from within the IDE. I know this will get beat up on the security side of things, but, java or C#, SOAP is SOAP. The security issues are there. The difference as I see it is that VS.net appears to make this so easy that the security issues must be dealt with now rather than later.
Java or C#, whatever. They are the same language. I like them both. The idea of multi language projects is laughable for the maintenance nightmare it presents. Eiffel would be cool, but, well, every time I champion it the other developers start looking at me funny.
My concerns about .net platform independance loom in the backround married to my scalability concerns.
I will cautiously plod down the j2ee path, but keep a sharp eye on .net hoping to to recover some of the productivity I use to have in C (DOS days) and PowerBuilder (C/S days). Who knows, I may even be able to build a distributed app in a real GUI again, instead of banging my and my users heads against these mindless, stateless browser interfaces.
</rambling>
Bill Pfeiffer
6 replies in this thread Reply
J2EE vs .NET
Posted By: Bernhard Messerer on March 22, 2001 in response to this message.
First: I'm sorry that your J2EE experience was signed by bad tools. I don't know SilverStream, but had a good impression from what I read; But I know very well what you mean... I restart WebLogic every 15 minutes.
However, you may want to try JBuilder (which isn't exactly cheap either because/but it comes with Borland AppServer) for a really fast development environment (of course, some things must be done, e.g. generating stubs, but three times faster than for e.g. BEA); you could exchange AppServer against Orion or jBoss, which do not require stubs to be present and the deploy cycle is even faster then.
Still, I think the best IDEs you can get are Java IDEs. For file based I like JBuilder best (this one is really great, especially the newer versions), but if you prefer a "modern" repository... well, VAJava does the job. And you can still look at Forte, WebGain, Kawa, AnyJ, IDEA... I think compared to VisualStudio they are all superior (and all with IntelliSense :-). And the AppServers... well, some vendors will have to learn, others got it.
But you are exactly right, many things should be done for the tools to be better... but your conclusion is 100% correct, let's always keep .NET in mind.
greetings
Messi
1 replies in this thread Reply
J2EE vs .NET
Posted By: Bernhard Messerer on March 23, 2001 in response to this message.
Another thing I'd want to mention about .NET: It again clearly shows you cannot rely on Microsoft and how bad vendor lock-in can get.
Because all Visual C++ and Visual Basic developers are now at a dead end (both will have to learn new languages, although C++ developers may have an easier time) which are the vast majority of people developing for Microsoft platforms.
Messi
1 replies in this thread Reply
J2EE vs .NET
Posted By: Damian Roskill on March 24, 2001 in response to this message.
Bill --
Found your comments very enlightening...thanks for sharing your experience with us regarding Silverstream. I've actually been considering Silverstream for a new project and would love to hear more details about your difficulties with the product? Is it that the tools are weak and undependable? How is the server itself?
No one has written a review of Silverstream in the Reviews section of this site - it would be great if you could take a minute to post your thoughts to help other developers before "we make the wrong choice"....
Thanks in advance!
Damian
0 replies in this thread Reply
J2EE vs .NET
Posted By: Roger Cornejo on March 27, 2001 in response to this message.
I havn't seen anyone point out that .NET is (will be) a product whereas J2EE is an architecture. I think that this is an importand distinction. In a sense it's like comparing apples and oranges. There are many vendors producing products based on the J2EE architecture, however, .NET is the only product based on it's architecture.
2 replies in this thread Reply
J2EE vs .NET
Posted By: Bill Pfeiffer on March 27, 2001 in response to this message.
.NET is a product that contains many of the features of the J2EE architecture:
Distributed computing model
Componant development
Transaction/Message based infrastructure
Web and/or Fat Client deployment choices
etc, etc,
That orange sure looks and smells like an apple!
2 replies in this thread Reply
J2EE vs .NET
Posted By: Roger Borg on March 29, 2001 in response to this message.
Is this a fair consideration?
.NET is probably ".NoWhere" if the U.S. Justice
Dept. prevails in its anti-trust trial
I think so! A breakup of Microsoft, as unlikely as it may seem, would undoubtedly have far reaching consequences for .NET.
0 replies in this thread Reply
J2EE vs .NET
Posted By: Werner Keil on April 3, 2001 in response to this message.
That Orange and Apple example was a very good one from the developer's point of view.
One has to assume .NET as the orange and J2EE (or Sun ONE?) as the apple. The apple (not connected to Apple computers :) is a lot easier to eat without extra tools you must buy (a knife,...) Especially if a problem arises - e.g. it contains a bug or worm - you can get a lot faster to its core. The orange is covered and protected by a strong skin and without any extra tool one can usually not get into it.
That seems to me like a great metaphor for the Open Source approach of Java and some J2EE components (Apache, etc.) vs. the propriatory (even with XML, SOAP, etc.) technologies of M$
Of course if you are used to orange juice (e.g because it's advertized better than the apples) and you can afford a big juice squeezing machine one might still be doing better with
the "orange".
1 replies in this thread Reply
J2EE vs .NET
Posted By: Jason McKerr on April 11, 2001 in response to this message.
I just wanted to make a quick reply to Bill Pfeiffer tools problem. I also am sorry to see that you have had problems with the tools. I've had a much better experience. I've used both WebGain Visual Cafe 4.x Expert and Borland JBuilder Enterprise (expensive) with JRun, Weblogic(just a test run), Tomcat, and JBoss with excellent success.
I especially like JBuilder since it is written in all java and will also run on Linux/Solaris. Debugging EJB's is also really easy with both with Inprise, JRun and JBoss. On the other hand, JBuilder is expensive, and it wouldn't run well it on any 'puter that has less than 256 meg RAM (I personally would get impatient with anything less than 512 meg RAM).
anyway, I know this is sort of an off-topic aside, but I just wanted to let Bill know that there is hope for the tools.
-Jason
0 replies in this thread Reply
J2EE vs .NET
Posted By: Dino Chiesa on April 12, 2001 in response to this message.
Everyone has his own biases.
But please consider what you are saying. MS is introducing new technology, new architecture, new language syntax, all rolled into .NET. Somehow this illustrates the horrors of vendor lock, and indicates that developers cannot count on M$. But didn't IBM do the same thing 2 yrs ago when they introduced their product called WebSphere? Didn't Spyder/Kiva/Netscape/iPlanet do the same thing several times over the course of 2-3 years? Didn't BEA do the same thing to their Tux customers when they bought WebLogic? While Microsoft may be forcing their developers to learn new tricks, M$ has no "monopoly" :) on _that_.
1 replies in this thread Reply
J2EE vs .NET
Posted By: Bernhard Messerer on April 12, 2001 in response to this message.
Yes, that is exactly what I'm saying: BEA, IBM, all others do the same thing. Apparently a vendor will always try to "Lock you in"... they don't want you to move to another vendor, although some put more and some less emphasis on this.
But what I mean is: YOu should never lock into one vendor, and that is exactly possible with Java. While there is J2EE now and to some degree we must admit that Sun wants to see "normal" Java Enterprise Apps as "legacy code" the J2SE is still developed and maintained, and you can still use your Enterprise Apps. Even better, you can do a slow migration.
This will probably be the same with MS, but do you know? They may cancel "traditional" VC++ soon (and it seems they will do this, abandon the "traditional variants" of VC++ and VB, and now try to migrate an old VB program to .NET... will be very funny I guess), and no one will hinder them. In contrast, as long as there is need, you'll always get a JVM I guess, if not from Sun, from IBM or any other vendor. Will you get a .NET implementation of someone else but MS?
So while iPlanet, Netscape and others may do the same thing you are always free to switch vendors, as long as you didn't let you "lock in".
The situation shows that things might come you'd never expect. WHo thought that MS would abandon MFC, VB, Win32 API and all those things so soon? After they used it for years although much better technlologies/methodologies were available?
Messi
1 replies in this thread Reply
J2EE vs .NET
Posted By: Deo Narayan Bhardwaj on April 13, 2001 in response to this message.
Hi
As I haveing the exp. in C/C++ and after that I moved to the java technologies and have experinece the maturity of technologies vs evolution of tech. , java is now going to be stable according to the bussiness need of today and MS is still in the process of development of new tech. , all the accessary is available for the sun , as for MS is for vb and COM. anway java tech is better then new one ??
deo
0 replies in this thread Reply
J2EE vs .NET
Posted By: Jon Strayer on April 13, 2001 in response to this message.
>NET is a product that contains many of the features of the J2EE architecture:
True. But it is only one product. There will be one platform for .Net. There will be one implimentation of .Net.
I haven't been doing J2EE for more than six months and I've already used three different implimentations of J2EE. Four if you could the WebSphere test environment that comes with VAJ.
The J2EE implimentation I'm using currently (Orion) runs on just about any platform with a JVM.
Having been free of vendor lockin for the last four years, I'd rather fight than switch. :-)
0 replies in this thread Reply
J2EE vs .NET
Posted By: Damian Roskill on April 17, 2001 in response to this message.
I agree - everyone wants to paint M$ as the bad guy from the standpoint of seeking a monopoly, but Sun is seeking the exact same thing with Java - a key foothold that cannot be eroded. I find this aspect of discussing the difference to bring out biases more than logic. The fact is that every one of these major companies wants to own the market -that's the business goal. I personally would not want to see M$ just lose out to Sun and have Sun be doing the same things that M$ has done. What I would like to see Sun do is open-source Java or spin it off...but hey, that's just me.
After three months of playing around with J2EE, I've now started playing around with .Net...and I have to say, I thought someone earlier had the best breakdown: MS has the tools, J2EE has the scalability and better tools for the large projects...
Now, what's it going to take to get a review of Silverstream on here? Seems like a great product, but hey, I'm not buying the hype right now....btw, Orion is a great product!
Seeya!
Damian
1 replies in this thread Reply
J2EE vs .NET - Swinglets
Posted By: Matt Stephens on April 19, 2001 in response to this message.
Swinglets was mentioned earlier in this thread. It's a toolkit for creating JSP/HTML/XML/WML pages from Swing-like components and data models.
IMHO this is one of Java's best kept secrets. I've used Swinglets successfully in a couple of projects. I found the author to be very receptive to feedback, requests for enhancement and bug reports (the product was in beta at the time, but still very stable).
The URL given was slightly incorrect. The correct URL is:
http://www.swinglets.com
Regards,
Matt.
0 replies in this thread Reply
J2EE vs .NET - We need better UI
Posted By: Shreedhar Mechri on April 25, 2001 in response to this message.
Well, try Sybase PowerJ for J2EE development. IMO, it has the coolest tools for developing and deploying EJBs, as opposed to handwritten XML DDs, et.al of BEA Weblogic.
0 replies in this thread Reply
J2EE vs .NET
Posted By: Rashid Jilani on April 27, 2001 in response to this message.
My 2 cents. Lets forget for a moment about .NET and J2EE. In the long time what matters a lot is the expertise. When we choose Java centric technologies we just spend our time once to learn the complex enterprise API’s and that is it. Example would be JTA. Just imagine a MFC programmer goes for MOTIF and vice versa. We don’t have to spend our time learning libraries again and again. It is trivial. What is more important is to understand the complexity of the domain and how to design a good Enterprise level application. Why I would learn win32 API, UNIX system calls or any other platform dependant API if I can almost always code against one interface (Java API). BTW so far in platform wars no one is winner and being a developer we all have to write code for lot of platforms. I bet lot of us already did that. And honestly I don’t want to learn new libraries again and again for different platforms. So my vote goes to J2EE.
RJ
1 replies in this thread Reply
J2EE vs .NET vs simplicity
Posted By: Alberto Gomez-Corona on May 3, 2001 in response to this message.
Wait wait wait...
I don′t understand. why are you so concentrated in the underlying bussiness platform? Why not to concentrate in the platform bussiness logic?. don′t we ear that the mission of the underlying middleware is to isolate the programmer form the complexities (the plumbing) of transactions, storage and so on?. If this is the case, J2EE, .NET or a third, will be part of the OS for the next generation of developers.
If we can not concentrate in the particular bussiness logic, the two platforms do not keep up with their promises. Something is failing in the concepts behing them.
from my point of view a _third_ platform, application layer or OS will achieve finally this goal.
maybe the simplicity is a heavier and better use of XML, and the intoduction of web concepts inside the application server and OS′s, the use of logic programming, messages instead of function calls, queues (pipes) instead of treads.
exotic, itsn′t?
1 replies in this thread Reply
J2EE vs .NET
Posted By: JAYESH PARAYALI on May 10, 2001 in response to this message.
I would rather use J2EE and stay away from .NET. I wonder what happened to former VJ++ developers.
With J2EE you have the option of deploying your application on linux/Solaris.
0 replies in this thread Reply
J2EE vs .NET
Posted By: Bernard Thouin on May 14, 2001 in response to this message.
Bill,
>>... in a real GUI again, instead of banging my and my users heads against these mindless, stateless browser interfaces.<<
How nice and soothing to see that some people have the same opinion as oneself about _that_ subject...
Bernard
1 replies in this thread Reply
J2EE vs .NET
Posted By: Toby Reyelts on May 14, 2001 in response to this message.
Bernard Thouin wrote:
Bill,
>>... in a real GUI again, instead of banging my and my users heads against these mindless, stateless browser interfaces.<<
How nice and soothing to see that some people have the same opinion as oneself about _that_ subject...
---------
Here, here! What is it going to take to move everybody to real internet applications?
God bless,
-Toby Reyelts
2 replies in this thread Reply
J2EE vs .NET
Posted By: Roger Borg on May 14, 2001 in response to this message.
Abhi
It has been over 2 months worth of "discussions" regarding the questions you posed.
I for one am curious if you and your company have come closer to a decision or reached a decision out-right?
If you have made one, what sort of pros and cons counted most? If you haven't yet made a decision -- are you leaning one way and why that way?
TIA
Roger
0 replies in this thread Reply
J2EE vs .NET
Posted By: Bernard Thouin on May 15, 2001 in response to this message.
Toby,
>>What is it going to take to move everybody to real internet applications<<
Probably a guy with a brilliant idea, but mostly with a superhuman charisma, not Bill Gates, NOT Sun, and who will convince the whole world that a browser is the worst invention on the surface of this planet when it comes to GUI capabilities, and that we should finally either go back to completely centralized solutions with graphic clients, or to "half-fat" (compiled, flexible) clients....:-)
Cheers
Bernard
0 replies in this thread Reply
J2EE vs .NET
Posted By: Stephen Bennett on May 15, 2001 in response to this message.
IMHO
I would think that we would all benefit if M$ and $un, etc. would all work together on these new frontiers.
All have great ideas to bring to the table.
"We need to get to a state of harmonic agreement on such structures as they will become a very important part of our future society."
Technologies are going into the making of our history and an influence on the Evolution of Mankind, MAN...... :-)
But how do you bring all these these mind-sets together?
Looks like only with the $, a symbol of our current state.
How about a Project whose goal is to Globalise the whole Technology Sector. We have some good Foundations and Objectives to get such a project started :-) There are loads of minnie efforts.....
BTW I would be interested in getting someones opinion, (insiders would be great)
How will Micro$oft operate when Bill Gates kicks the bucket, Crashes?
What will life be without this Central Serving Computer Chip?
When someone presses the big M$ reset buttonm will we wake up to a Brave New World?
0 replies in this thread Reply
J2EE vs .NET
Posted By: Bernard Thouin on May 16, 2001 in response to this message.
Toby,
>>What is it going to take to move everybody to real internet applications?<<
BTW, I thought afterwards, there already IS a good solution to that problem (and I already hear the horror shouts): Citrix.
That allows a complete, singing and dancing, good-old-times, GUI-rich Windows application to be used from within a browser or on its own, but it runs on a central server, and you only see the presentation part of it, so to say, on your PC.
So think about it that way:
- no redevelopment AT ALL
- full Windows GUI capabilities (multiple windows, all mouse actions, "block mode" or not with highest speed
- no fiddling with app servers, Java, JVM, EJBs, CPM, session/entity beans, persistence, ... you name it
- no stupid, slow browsers
actually, only advantages: take you good old client/server, 2 or 3-tier app (be it a VB, PowerBuilder, Delphi, Centura, whatever one)... and put it on the Net !
OK, it's clearly not "web-native", but so what ? Most mortals (our typical users...) wouldn't notice the difference anyway, except that they will LOVE a real GUI...
:-)
Bernard
1 replies in this thread Reply
J2EE vs .NET
Posted By: Frank van Moorsel on May 17, 2001 in response to this message.
>BTW, I thought afterwards, there already IS a good
>solution to that problem (and I already hear the horror
>shouts): Citrix
How well does it scale? Can it support all applications without any modification?
>actually, only advantages: take you good old client/server,
>2 or 3-tier app (be it a VB, PowerBuilder, Delphi, Centura,
>whatever one)... and put it on the Net !
Taking your 2-tier client/server as is means inheriting the same scalibity problems, even worse you need at the Citrix level high capacity hardware to support a lot of concurrent sessions and at the database level you also need high capacity hardware to support the amount of concurrent database connections (which equals the number of concurrent Citrix seesions because there is nog resource pooling like on a appl server). What would be the sollution to the 2tier scaling problem? Move to a 3- or n-tier architecture, meaning "- no fiddling with app servers, Java, JVM, EJBs, CPM, session/entity beans, persistence" is not entirely true.
0 replies in this thread Reply
J2EE vs .NET
Posted By: Girish Eashwar on May 17, 2001 in response to this message.
Bill,
I too had worked with Silverstream and i can understand when u crib about its features. I have had my share of problems with other tools like Kawa's IDE also.
Recently we had evalauted Pramati's IDE , which they call Pramati Studio and it turned out to be a very good tool for server side development. The tool has excellent support for EJB's and it comes with a test server.
Its deploy tool is very easy to use.
Miguel
0 replies in this thread Reply
J2EE vs .NET
Posted By: Steve Hill on May 17, 2001 in response to this message.
IMHO...
The two enterprise architectures at the moment are WinDNA and J2EE. The .Net platform will only be realized when things like ASP.net, C#, and ADO.net become a reality (i.e. SQL Server 2000 is a great product but it seems silly to call this part of the development Architecture). The timing of this makes me think of the MS PDC 3+ years ago when we were first got a taste of COM+, and then couldn't really use it until Win2000 Server SP1.... don't expect to really build .Net applications until at least mid-2002.
In my experience developing several applications on both WinDNA and J2EE platforms, the two architectures break down this way in terms of advantages / disadvantages they offer...
J2EE
* JSP / Servlets: (+)Multi-threaded, (+)Faster than ASP, (+)Extensible Tags, (+)full Java language for tag classes and scriptlets
* Language Support: (-)Java only, (+)fully object-oriented
* Security Model: (-/+)not integrated with platform
* Service-Oriented System Objects: (+)Stateless session beans are automatically pooled objects, (+)Stateful session beans automatically tied to user context, (+)Stateful session beans support persistence, (-) vendor implementation of persistence mechanisms are inconsistent and not part of the current EJB 1.1 specification
* Service-Oriented Data Objects: (+) Container Managed Persistence promotes rapid development, (-) Container Managed Persistence deployments have limited portability for migrating between J2EE vendors which can lead to re-work, (+)Bean-managed persistence allows for legacy integration and manual transaction demarcation, (-)Bean Managed persistence promotes long and complex development tasks, (-)Entity Beans do not handle data retrieval at high volumes of data as well as a stateless data access layer, (+)Entity Beans are an elegant design metaphor for representing relational data, (-)Entity Beans must be used with care since the concept of an single enterprise data representation can create artificial concurrency bottlenecks that might otherwise not exist using a stateless DAL (i.e. composed of stateless session beans) against an RDBMS
WinDNA
* ASP / ISAPI: (+)ASP has reasonably good performance, (-)language features are limited, (+/-)loose typing
* Language Support: (+)ASP supports a pluggable script interpreter so you can use VBScript, Javascript, Perl, etc.,
(+)COM objects can be built in a number of languages, (-)VB, the most popular WinDNA language, does not support parameterized initialization or polymorphism
* Security Model: (+/-)Integrated with platform
* Service-Oriented System Objects: (+)COM+ deployment simpler than EJB deployment, (+)VB components can be built more quickly than EJBs, (-)no support for automatic object pooling unless you use C++, (-)limited support for stateful components, (-)difficult to achieve loosely coupled vb components across system and data tiers since ASP to COM+ interface cannot bind to secondary interfaces except through named calls (i.e. interfacename_methodName) which actually creates additional overhead (IDispatch is the only way for VB components to bind)
* Service-Oriented Data Objects: (+)WinDNA maximizes scalability through advocating stateless components (i.e. application DAL components, base DAL components), (-)WinDNA lacks any convenient representation of persisted data as an object
To me, the PHP route is valid only for applications where horizontal scalability is not a concern, and maintainability is not a priority.
1 replies in this thread Reply
J2EE vs .NET
Posted By: Steve Hill on May 17, 2001 in response to this message.
IMHO ...
.Net Is Based on COM+ ... download the .Net framework and the beta release of visual studio, build a web service and connect to it.... check out the objects that get built behind the scenes
.Net is not COM+ though and you don't need to know COM to do .Net, but the infrastructure is using all kinds of COM-like object interactions. The big difference is the CLR.
1 replies in this thread Reply
J2EE vs .NET
Posted By: Frank van Moorsel on May 18, 2001 in response to this message.
>IMHO ...
>.Net Is Based on COM+ ... download the .Net framework and
>the beta release of visual studio, build a web service and
>connect to it.... check out the objects that get built
>behind the scenes
>
>.Net is not COM+ though and you don't need to know COM to
>do .Net, but the infrastructure is using all kinds of COM-
>like object interactions. The big difference is the CLR.
I agree, .Net applications will use (existing) COM+ runtime services for e.g. transaction management, role based security etc. .Net (the CLR) will bring another (a far better) component/object model to Windows development, a model which has IMHO features already found in the Java model (some remarks on this new programming model see: Don Box column House of COM on http://msdn.microsoft.com/msdnmag/issues/1200/com/com1200.asp) A quote from Tim Ewald's book Transactional COM+ , appendix A: "The CLR is a replacement for COM, but not for COM+. CLR classes can be configured to use COM+ runtime services the same way COM classes do. In fact you can mix both classes using both component technologies in the same COM+ based system. This works because the CLR is backwards compatible with COM. The .Net Framework SDK simplifies COM+ programming...."
0 replies in this thread Reply
J2EE vs .NET
Posted By: Frank van Moorsel on May 18, 2001 in response to this message.
Steve,
Very good comparison, compliments!
2 questions:
> don't expect to really build .Net applications until at
> least mid-2002
do you really mean build or do u mean deploy? in your opiniun can larger projects start designing and building using beta1/beta2/RTM and deploying when the VS.NET product is stable enough (SP1)?
(projects where development starts Q3/Q4 this year and where delpoyment will be Q3/Q4 next year, and projects where .Net as outlined by MS now may for several reasons be a valid choice)
>In my experience developing several applications on both
>WinDNA and J2EE platforms, the two architectures break
>down this way in terms of advantages / disadvantages they
>offer...
supose we are at mid-2002 and .Net is reasonably stable, how does your J2EE vs .Net advantages/disadvantages list look like? I see in the J2EE advantages list and WinDNA disadvantages list some issues which will be addressed in .Net (a quick scan of your list Faster than ASP, Extensible Tags, full Java language for tag classes and scriptlets, fully object-oriented, loose typing, no support for automatic object pooling unless you use C++, limited support for stateful components, (-)difficult to achieve loosely coupled vb components across system and data tiers since ASP to COM+ interface cannot bind to secondary interfaces except through named calls (i.e. interfacename_methodName) which actually creates additional overhead (IDispatch is the only way for VB components to bind), WinDNA lacks any convenient representation of persisted data as an object)
2 replies in this thread Reply
J2EE vs .NET
Posted By: Damian Roskill on May 18, 2001 in response to this message.
>supose we are at mid-2002 and .Net is reasonably stable,
>how does your J2EE vs .Net advantages/disadvantages list
>look like?
The decision of J2EE vs. .NET becomes a lot more difficult and a lot clearer. Basically, .NET will be easier to use and deploy (I've been using Beta 1 and it's pretty good) when compared with J2EE (particularly with EJBs)...and J2EE will have the advantage of being able to deploy on a large variety of platforms.
So, leaving out scalability (a huge question which neither J2EE nor .NET can answer right now), your decision will come down to whether or not you need to support multiple platforms.
If the answer is yes, J2EE is for you. If the answer is no, then .NET will provide, imho, a significant productivity boost over J2EE.
Some additional thoughts:
- J2EE server prices need to come down. $10k a CPU makes the "deploy anywhere" idea a waste of time in terms of horizontal scaling. Who cares if I can put my J2EE on a $2k Linux pizza box if the license costs me $20k for 2 CPUs. Then add in the cost of a good development tools and you're spending a fortune.
- J2EE will continue to be the fav of those looking for large scale enterprise applications. .NET will hit at the low and mid-market developers that make up a large percentage of all development done today.
/d/
1 replies in this thread Reply
J2EE vs .NET - The cost issue
Posted By: Ganesh Prasad on May 24, 2001 in response to this message.
> - J2EE server prices need to come down. $10k a CPU makes
> the "deploy anywhere" idea a waste of time in terms of
> horizontal scaling. Who cares if I can put my J2EE on a
> $2k Linux pizza box if the license costs me $20k for 2
> CPUs. Then add in the cost of a good development tools
> and you're spending a fortune.
Absolutely. And I thin
