站内搜索: 请输入搜索关键词

当前页面: 开发资料首页J2EE 专题J2EE vs .NET (1)

J2EE vs .NET (1)

摘要: I am working with my company's IT Division to decide the future direction of the Architecture f...
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
↑返回目录
前一篇: J2EE vs .NET:赛前称重
后一篇: J2EE vs .NET (2)