Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Java v. .Net? 39

Posted by timothy from the yards'-worth-of-hedging dept.
JEmLAC writes: "Fawcette's running an interesting piece (in conjuction with JavaOne) on a presentation by Gartner analyst Mark Driver concerning the emerging niches for Java/J2EE and .Net in the deployment of Web services. His take is that by 2005, they will be co-standards."
This discussion has been archived. No new comments can be posted.

Java v. .Net? More

Java v. .Net?

Comments Filter:

  • We develop a lot of web apps, and we keep wondering if .NET and Soap and Webservices and whatever else _really_ work yet. Clients do want it (though they seldom know why). We still implement things with pop-under data retrieval and the like.

    Anyone out there done a large project using MS's new web philosophy? How has it gone?

    .
    • Another important question: Has anyone succeeded at using SOAP to crack a "web services" server?

    • Re:Right now... (Score:3, Informative)

      by Why Should I ( 247317 )
      I'm currently in the middle of implementing a large scale, customized CRM system for a global company.

      They insisted on using MS technologies (server maintenace would be easier they said).

      So we decided to use .Net because we needed a system wide platform to build all the customisations on. I would rather have used a more mature technology (Enterprise Java anyone) but MS was insisted upon us.

      When I first started to get into .Net all the right ups and books about it got me excited. It really does bring everything you need to build a web application into one platform. The problem ...

      There are far too many cracks that things fall through. All the little nitty gritty things that you don't want to become intimately involved with when building an enterprise system, do exactly that, force you to get intimately involved with the low level stuff.

      If I wanted to do low level work I woulda used a custom built platform (combo of server scripting, php or asp, and my own server side binaries with all the funky stuff in it). But no, we chose to go .Net because it "did everything".

      Yeah it did everything alright, just not completely.

      For example, anyone tried printing the contents of a rich text box control? Why use a prepackage rich text box control if you have to right your own low level rtf parser to print? how furked up is that?
      • Sort of what I expected...

        Good solution to most things, but riddled with gotchas...

        On a side note, we adventured with the rich text box too - we ended up implementing printing via the DHTML edit control in IE 5.5 (with a custom print template). That's a mess too, if you're wondering...

        Thanks for the heads up.

        ...

      • Can != Should (Score:2, Insightful)

        by Tablizer ( 95088 )
        (* For example, anyone tried printing the contents of a rich text box control? Why use a prepackage rich text box control if you have to right your own low level rtf parser to print? how furked up is that? *)

        Just because you *can* use a RTF widget does not mean you should. Are you yelling at MS because they gave you the *option*? (Perhaps if they didn't give you the choice of regular HTML approaches, then you have something to fuss about.)

        Choice is not evil, but the misuse of it.

        Personally I think B-to-B and intranet web interfaces will disappear when a decent HTTP-friendly GUI standard finally catches on. Customers, developers, and managers *keep* asking for web apps to act like GUI's, and they don't do that very well. Web interfaces are fine for active brochures, but crappy for medium-duty business forms.

        Also, is it possible/practicle to run a Python interpreter on CRL/.Net? It seems that CRL favors staticly-typed languages. I like good scriptish langs myself.

        • You can only make a good choice if you have all the information.

          The problem is that MS presents these options as good ideas, then shafts you when you're a month into development.

          When you're looking at the examples and the docs, nowhere does it say "Oh yeah, when you go to print the contents of this box, you're screwed."

          They don't say, "Oh yeah, we're going to make sure you can't do that in IE 6.0, even though you depended on it in IE 5.5".

          That's why I asked the original question about how ready .NET web apps were.

          MS always has great developer's tools - as long as you are doing the things they thought of.

          In other news, I'm sure the CRL could certainly accomodate more "scriptish" languages, though I haven't heard of any Python projects.

          .
          • (* "Oh yeah, when you go to print the contents of this box, you're screwed." *)

            I rarely see docs from commercial companies that say what something *can't* do. Your expections seem a little high. Does Sun regularly do that?

            (* In other news, I'm sure the CRL could certainly accomodate more "scriptish" languages, though I haven't heard of any Python projects. *)

            Well, I am sure it is technically possible due to "Turing Complete", etc. etc. However, I suspect its practicality.

            How about this question: What is the *most* scriptish language currently available (or at least in alpha) on CRL?
            • I rarely see docs from commercial companies that say what something *can't* do. Your expections seem a little high. Does Sun regularly do that?

              I'm not saying that MS is evil. I'm saying that sometimes you make a choice without all the information. Read the thread.

              How about this question: What is the *most* scriptish language currently available (or at least in alpha) on CRL?

              I suppose it depends on what you mean by "scriptish". I'm guessing from the thread that the most important "scriptish" feature is loose typeing.

              There are no real loosely typed languages in .NET - but probably VB.net gives the best idea of how they'd implement one. They replaced Variants from VB6 (which also worked well enough in the very loosely typed VBScript) with a wrapper class that does the same thing (and yes, I haven't actually used them).

              I don't know why this would be a particularly hard chore for the CLR. All it means is calling a function or two every time a variable is referenced. Lots of overhead - same as you'd get from the script interpreter doing the same calls.

              .

              • Re:Can != Should (Score:2, Informative)

                by Why Should I ( 247317 )
                The technique is called "Boxing" and it is how .NET enables the use of value native data types (i.e. ints, floats, bools etc) as actual objects. see example below

                int testInt;

                testInt.Parse("600");

                testInt is a value type so theoretically isn't handled as an object (its placed on the stack, not the heap). But in order for us to use the Static methods of the int class we need to "Box" the int, so we can treat it like an object. THis is basically placing an object wrapper around a value type (i.e. dereferencing it in the heap etc).

    • Re:Right now... (Score:2, Informative)

      by Anonymous Coward
      We are porting some java sites to asp.net, and have been very happy with the results. As to your comment 'rarely know why' - here is why we are doing it: 1) Cheaper hardware - replacing overpriced Sun and HP boxes 2) Very clean design/coding methodology - nice code separation 3) Performance - we are seeing 2-20x perf gains with ASP.net over Java equiv 4) Excellent error handling 5) Nice caching infrastucture 6) Data access layer that makes Java look like a beta product 7) Great integration of SOAP/XML 8) Good degugging

      Overall, the platform has may advantages and is a pleasure to code in with the VS.Net IDE. We are not looking back.
      • AC, since you seem to have real life experience with .NET, it would be interesting to get more specific information.

        My thoughts on your post:

        1) Java runs fine on the same HW as .NET, plus you can get alot of the software for it for free. Running on Unix boxes is just a way to scale up Java, something that is not available for .NET.

        2) Same for Java.

        3) Performance is often better for asp, what are your specific applications and platforms ?

        4) Examples ?

        5) Java has this too. Nice infrastructure that is.

        6) What do you mean by data access layer ? Java is excellent for data access.

        7) Java too.

        8) Most java tools have this too.

        • I haven't done any Java-to-.NET porting, but there are examples out there.

          I recently attended a .NET Overview Conference here in NYC. Most of the conference was fluff, but one of the interesting topics was a CafePress case study. CafePress swithced from Java to .NET, you can find an overview of this here:

          http://msdn.microsoft.com/netframework/prodinfo/ ca sestudies/cafepress/default.asp

          The two metrics that stuck out were that the rewrite took 80% less lines of code (mentioned at the conference and not the article. Most of the code saved was in the data access layer), and that CPU usage dropped from 50-70% to 2-3%.

          This is not an independant study, so there is no mention (if any) of the cons of using .NET. However, those are some pretty impressive gains.
  • Don't we have interoperable standards now? What about SOAP? Doesn't this bring common solutions today?

    • Re:what about SOAP? (Score:2, Informative)

      by grungeKid ( 4260 )
      SOAP is the external interface of the web service. The idea is that you implement this interface using Java or the .NET framework.

      Of course, a SOAP-compliant web service could be implemented through Perl, C, shell scripts, REXX or specially-trained gerbils, the client program using the web service shouldn't know (or care).

  • Pipe Dream (Score:2, Interesting)

    by cs668 ( 89484 )
    All of this talk of web services and WSDL/SOAP repositories reminds me of how people used to talk about objects, object repositories and CORBA.

    I think it is just another big marketing load of crap. Sure WSDL/SOAP work, but so does CORBA/IIOP. The problem is it is just a pipe-dream. What are the chances that a company will have a complex service, which solves my business need, that I can just plug into. Sure they may have some simple common services - even complex ones(that will not fit meet my need). But, the integration costs will not go away.

    Sorry about ranting - I just get sick of hearing the same things repackaged as the ultimate solution every 4 years.

    • Re:Pipe Dream (Score:3, Informative)

      by Anonymous Coward
      Ah, but you fail to see how much faster it is to deploy SOAP based web services than CORBA/IIOP.

      If you are averse to .NET or develop on a non-Windows platform, why not give Systinet's WASP web services a try (http://www.systinet.com)? The Lite version is free even for commercial use, and the C++ implementation is open-source. It automagically generates all the stub code for you from Java skeleton classes.

      Go ahead and follow their hello world example, and time how long it takes you. Then go do it in CORBA and ONC/RPC. :)

      The whole point of Web Services is true interoperability and abstraction of the transport, while still giving you the means to tweak the transport as necessary for your distributed apps.

      It is much bigger than Microsoft, and much more than hype. WS hype is like XML hype. Yes XML is useful, though the hype can cloud judgement over what to use it for and what it will do.

      Nuff said, web services rock. BTW WASP works great with .NET! (And they're not paying me for this post...)

      esac
      • I've done both CORBA and Web Services and if you use tools with the same level of sophistication they are about the same level of difficulty. One advantage Web services do have is that they can eliminate transport layer issues that crop up with CORBA and firewalls. You don't address the original point, which is that the cost isn't in making the object available on the network; it's in designing your system so it integrates with network objects in such a way that the network objects do you any good and your performance does not go to hell.

  • .NET is overall a good thing. (Score:3, Insightful)

    by mmusn ( 567069 ) on Thursday March 28, 2002 @12:39AM (#3238870)
    Love to learn the bomb, and realize that .NET is overall actually a pretty good thing. First of all, it moves the Microsoft world away from Visual C++, and VB. This will result in Windows programmers that are used to working and thinking much more like the rest of the world. It will also result in Windows programs that are more reliable and easier to port to other platforms.

    The C# language and core libraries underlying .NET are also well-documented and standardized. This means that free and third party implementations are going to happen (in fact, Mono is almost there), and a lot of free code can move more easily between the Windows and non-Windows worlds than was possible before.

    And Sun needs the competition. The threat to their business from C#/.NET may finally get Sun to open up Java more. And it may get Sun to finally address some serious limitations of Java and the JVM that they have been promising to address for years but failed to do anything about.

    In the long run, I think the two platforms will just merge. Runtimes will simultaneously support JVM and CLR, and Java and C# compilers will target each others runtimes.

    All this is good as far as I'm concerned. I'm using Java for a lot of my work right now, but I may give Mono a try once it is fully self-hosting on Linux.

  • I was hoping that .NET would slap Sun hard enough to make them improve multi-language support in the JVM. At least put in the tail-call support that Guy Steele originally wanted. However, from quotes in the article it seems Sun isn't getting enough heat.

    "No shop that's already Java-established is contemplating .NET. Java is holding its own," [Gartner's Mark Driver] stated.

    Although this two-world reality should come as some comfort to either party, Sun Microsystems doesn't always acknowledge it. "Sun takes an arrogant tone [at times] that Java has won the war," he explained.

    ...

    Don't Web services change all this? According to another Gartner survey, 58 percent of developers are currently developing Web servicesto which Driver cheekily added that they probably only think they are. In any event, when it comes to the technologies used today for building Web services, 37 percent claimed they were using .NET, while 76 percent said they were using Java.

    • Sun is going to have to come to their senses about this relatively soon. Resting on their laurels while MS funds a massive marketing strategy could end up crushing Java-- remember that almost everything MS is touting about .NET has already been in Java for a long time, but they're not treating it as a "better Java", but as something completely new. (Those tricky thieves...)

      The article suggests that Sun should focus on training more developers. As a student raised on Java, I think they're already in a good position here, but MS is currently on a push to get .NET taught at many of the elite universities as well. Doing some things better than Java (with a decade of hindsight) gives them an edge here...

      Now's a perfect time for Sun to reinvent Java a bit. Things like generics and the tail call optimization, for the researchers, but more importantly, a general push to the public again. Face it, there wasn't much fanfare when Java 1.4 was released. It's time to get excited about it again, is Java is going to hold out...

  • I love this guy. You read the article, and by 2005, it sounds as though Java and .NET are going to be all there is. 70% of corporations use VB now, he says. Yada yada yada.

    The thing is, you can't even write much of the stuff that gets developed today in either Java or .NET. You cannot write low-level stuff, like OSes and device drivers, where C is still a dominant contender. You are hard-pressed to write embedded stuff, though I'll grant that Java has some potential there if the momentum gets going. You'd be equally hard-pressed to write instrument control applications, with their combination of low level and performance requirements; many of these are currently written in C++. Neither Java nor .NET is even slightly appropriate for high-performance scientific work, where FORTRAN is still the ruling candidate by a long way. You get the idea. Apparently, things like C, C++ and FORTRAN will have disappeared in three years!

    Whatever the speaker concludes about Java and .NET, he does the programming world a disservice by completely glossing over whole markets, which are at least as important as "enterprise apps" (big databases, and about the only people who are ever going to care about "Web Services"). IMNSHO, neither Java nor .NET will be nearly as significant in three years time as this article would have you believe.

    • You're rather missing the point here, I think. The stuff you mention is mostly done at universities & research labs, and by corporations doing embedded (vcr, nailgun, electronic stapler, calculator etc) work or actually developing hardware.

      If you need to go down deeply into the bowels of a machine, sure - use assembler or C. That's what they're for. But they are NOT contenders in developing business applications.

      He is talking about *businesses* (i.e. FOR PROFIT) doing work on *business applications*. This means boring, dull stuff like invoicing, procurement, human resources, payroll, sales, crm, inventory management, word processing, etc.

      You know - the boring things that businesses for some strange reason seem to have a knack for in order to stay in business.

      Both Java and .Net are squarely targeted at this kind of development, and so are most commercially available web services (airline times, weather reports, customer data, marketing data and so on).

      This is the arena in which most developers work - actually helping to improve business processes for corporations. Not developing some archaic routine to calculate the angle at which a car's suspension system need to be at to attack a particular curve in the best way. That sort of work can be handled (and usually IS handled) by internally developed 4GL languages based on C++ or C.

      • Well, one of us is missing the point, anyway. :-)

        I'm well aware of what "business applications" are; I work at a software house that does both "business" and "engineering" work. I'll grant you that Java and .NET are targetted principally at business apps, and that business apps are likely to be the only things that care about Web Services. However, with all due respect, your claim that this is the arena in which most developers work is utterly falacious. There is far more development work done outside of business apps than in it. This is supported both by every survey I've ever seen, and simple, objective measures like how much business my employer gets in each area.

        IMHO, the focus on new technologies for business apps rather than engineering ones is more due to the low maturity of tools in that field and the scope for improvement -- there is a lack of good tools at present -- rather than the fact that there is more need for tools in the first place.

        And so, I stand by my original point. While there may be only two big players in the business apps market by 2005, there will still be many more in the market as a whole, and most of them will be old and established things like C and FORTRAN, not new, immature technologies like .NET. I feel that the article was misleading in this respect.

Slashdot Top Deals

"When the going gets tough, the tough get empirical." -- Jon Carroll

Close