comparative researche of .NET J2EE

I have never said I will get unbiaised answers. I am interessing about your opinion (as objective as possible) and after it is my work to check the information and select the relevant arguments.

For the second point, my study is not for developpers but for the project manager assisting the project owner especially for the choice of environnement (.NET / J2EE) at the beginning of some projects.

So if you have any idea about the :

- portability

- stability

- technical use

- connectivity

- security

- cost

- scalability

of J2EE (and/or .NET) I will be glad to read you!

olemarreca at 2007-7-9 22:50:00 >

LAMP is NOT a "technology", it's just a name for a combination of technologies which have nothing per se to do with enterprise application development.

The choice of JEE vs. .NET is mainly one of personal preferences of the people involved, and the skillsets and equipment available.

If a customer has a large existing investment in Windows technology I'll not usually tell them to use JEE.

OTOH if that same customer with the same project requirements has a server environment centered around Unix machines I'll be unlikely to advise them to use .NET.

In either case the potential benefits of the rejected technology is more than offset by the cost savings of not having to invest in training, hardware, and software they have no experience with.

I'll tell them that even if it means I cannot implement the solution for them, as implementing something that one knows it not good for the customer will only be bad for you in the long run. Unhappy customers mean less future business.

both platforms are extremely versatile and capable, so much so that there's usually (talking purely serverside) there is no technical reason to choose one or the other.

Clientside, if customers will want a Windows based solution, the choice is usually clear (though Swing applications can work, often customers want native Windows solutions).

If the customer wants a web interface, there's again no technical reason to choose one technology over the other.

jwentinga at 2007-7-9 22:50:01 >

LAMP is NOT a "technology", it's just a name for a combination of technologies which have nothing per se to do with enterprise application development.

How do you define "enterprise application development" then?

LAMP is a "technology" because that word has no predefined technical meaning and it's a reasonably applicable use of its common usage.

Moreover you can use that combination of tools to build much the same sort of site as can be built with the J2EE stack or the .NET gizmos.

Personally LAMP is not to my taste as I'm rather fascist about my database requirements, but claiming it has nothing to do with developing enterprise applications seems to be an abuse of the terminology. Unless you can cite an authoritative reference that precludes it, of course. Seems rather unlikely.

dcmintera at 2007-7-9 22:50:01 >

> LAMP is a platform on which systems can be created.

Or "applications" as we describe them.

> It's not an application development environment.

That's just stupid.

> It's also far from enterprise

"Enterprise" doesn't have a single distinct meaning. Enterprise systems are systems that run across the enterprise. Somewhat self-referential, but if businesses elect to built their enterprise-wide applications on LAMP, then LAMP is an enterprise system regardless of your prejudices.

>, as php and mysql

> aren't suitable for largescale, secure, scalable, and

> maintainable systems.

That's also garbage. Any technology can cover all these bases if it's used competently, again, your bias against them not-withstanding.

PHP and MySQL can both be used to build large, secure, scaleable and maintainable systems.

That they are more often used to build toy websites doesn't change that. PHP and MySQL both have major disadvantages, and I would not choose them for a project that I was involved in, but to claim that they are not used to build the types of application that they patently are is extremely foolish.

It's not like you can't build toy insecure unscaleable and unmaintainable systems in .NET and J2EE, now, is it?

D.

dcmintera at 2007-7-9 22:50:01 >

> LAMP is a platform on which systems can be created.

J2EE is a platform on which systems can be created.

> It's not an application development environment.

I have to assume you're kidding, or using some extremely bizarre definition of an environment in which one develops applications. Either way, it's hard to take that statement seriously. Can you explain what you mean by it?

> It's also far from enterprise, as php and mysql

> aren't suitable for largescale, secure, scalable, and

> maintainable systems.

Patently false. LAMP is used in the enterprise, and is suited for large-scale, secure, and maintainable systems, notwithstanding that it's also extremely easy on which to build trivial applications; please refer to my previous link for an enterprise-ready example.

It sounds like you're just falling back on nonsensical dogma with respect to LAMP. Nothing you've said about it so far resembles reality and actual practice.

~

yawmarka at 2007-7-9 22:50:01 >

> My definition of technology might be odd, but I agree

> that LAMP isn't a technology.

Neither, by that definition, is Java EE. I really find this "LAMP isn't a technology" angle to be pedantic ballsniffery at its extreme. :o)

Yawmark (< <insert programming language> isn't a real programming language...)

yawmarka at 2007-7-9 22:50:01 >

you still don't understand?

LAMP is just a marketing term (made up by O'Reilly I think) for a grabbag of open source products.

It's no programming model or anything.

Saying it's the equivalent of .NET or JEE is like saying that a bag of apples is the equivalent of an orchard.

jwentinga at 2007-7-21 17:46:02 >

> you still don't understand?

> LAMP is just a marketing term (made up by O'Reilly I

> think) for a grabbag of open source products.

So what? That doesn't mean it's imaginary, or that it's not an application, or that people don't use that combination of technologies.

J2EE is a marketing term, and so is .NET - LAMP is a marketing term coined to push books on a technology stack that was already in widespread use.

> It's no programming model or anything.

I have no idea what you mean. Is J2EE a programming model? Is .NET?

> Saying it's the equivalent of .NET or JEE is like

> saying that a bag of apples is the equivalent of an

> orchard.

Saying that a selection of technologies is like another selection of technologies is like saying that a collection of apples is like another collection of apples.

And making up your own terminological distinctions isn't really proving anything except that you don't like LAMP. Ok. We get it. Again, so what?

dcmintera at 2007-7-21 17:46:02 >

> > Is the developers productivity satisfying?

> Are you really asking if the developer likes their

> job ? Has nothing to do with the language used, more

> workplace and company - see human resources course.

>

Wrong. I left my last job because of the language/system they were using (which they wanted me to move to after they closed down their Java development).

I used it for a while, but it was completely unsatisfactory. The people, workplace, company all didn't change. The work itself did and that change was at least to me one that was to the worse to the extent that I could no longer work there and have any job satisfaction at all.

But that's a matter of personal preference, what one person likes another may not.

jwentinga at 2007-7-21 17:46:02 >

> Check Rima Patel's comparative analysis on DOT NET and J2EE platforms.

Now that's a biased opinion!

By the way, I don't know if the OP has learned a lot from the previous discussion.

I've been active in .Net world and for some time in Java development. I think they are 2 not that different technologies. From what I know, both provide techniques to accomplish the same goals.

However there is a great difference in the way of thinking between the general .Net developer and the J2EE developer! J2EE developers spend more time in business code whereas .Netters start of designing their web interface first. A lot of the attention in .Net goes to what visual studio can do for you. This is a dangerous way of programming: click a little here, drag something there, type a few things in a wizard and voila, your application is ready. But then the nightmare of maintenance begins!

However there are also enough documents of how to implement enterprise patterns in .Net, guidelines and stuff on MSDN for those who are interested in it.

I agree with Whitemerovingian that in rich client environments Microsoft's approach to RAD is quite appealing: a lot of preshaped components you can drag and drop and a lot of possibilities to just cramp everything into you window class without getting in too much trouble. I don't have much experience with Swing or JFC, but it's not too inviting to start with.

On the OP's question on portability: both are quite portable since they use the principle of virtual machines. But I think they look at it from different sides: Java's VM was intended to run on different OS, while .Net's VM was intended to connect different languages. .Net is also portable to other platforms but its code will run more optimised on Microsoft platforms.

Peetzorea at 2007-7-21 17:46:02 >

> That would have been deliberate, as his question

> made no sense and we were trying to show him that.

Quite. Fat chance that he'll get the message, but you've got to try, haven't you?

> And Sun is pushing JEE in that way by means of their

> ever greater integration of things into Netbeans.

> I fear the next release may be incapable of working

> properly without Netbeans, just as many .NET things

> are only properly possible when using Visual Studio.

> Think of making deployment possible only from within

> Netbeans, which would effectively force people to use

> Netbeans for everything.

I think you're being paranoid. Any standard that mandated such a thing would not be adopted. Sun may well be pushing integration with NetBeans (I don't know as I don't use it) but they're not particularly neglecting the all-important command-line either.

A standard that mandated NetBeans would not be adopted; NB doesn't have enough market share to sway the masses. Besides, how are you going to integrate NB into a continuous build system? Most shops I've worked in would reject it on that basis alone.

The one area that I think Java has a significant advantage over the MS toolset is that it has a more diverse ecosystem. Even if Sun were so inclined (and I think they aren't) I really doubt they could put much of a dent in it.

dcmintera at 2007-7-21 17:46:02 >

>And Sun is pushing JEE in that way by means of their ever greater

>integration of things into Netbeans.

>I fear the next release may be incapable of working properly without

>Netbeans, just as many .NET things are only properly possible when

>using Visual Studio.

>Think of making deployment possible only from within Netbeans,

>which would effectively force people to use Netbeans for everything.

I think that it will be harder for Sun to achieve this tight coupling because there is already a wide variety of application servers implementing the JEE specs. I can't imagine they will all go to NetBeans. IBM based all of its development tools on Eclipse (WSAD, RAD, Websphere ICS workbench...), BEA has its own Eclipse mod with tons of (not all equally necessary) plugins...

> Same thing can be done easily with Swing.

Swing can do everything .Net can, but I think .Net is a little more accessible (IMHO).

Peetzorea at 2007-7-21 17:46:02 >

I not saying that it cannot be done in swing, in fact swing since its more basic, gives you more flexability to developed components from scratch, but what am saying is that in Microsoft/Borland RAD its faster executing in the context of Windows Worstations, faster in developing rich clients. and far more already "out there" tools to begin with, which gives the developer more productivity(which another subject, not be be discussed on this topic).

cheers =)

Whitemerovingiana at 2007-7-21 17:46:02 >