Sun's new LX50 Server a bet on Java, Competitive with .NET

Discussions

News: Sun's new LX50 Server a bet on Java, Competitive with .NET

  1. Earlier this month, Sun announced plans to offer the Sun LX50, a 32-bit Intel-based, entry level server, pre-integrated with Linux and the entire Sun One software stack (including the AppServer). Recently, a study concluded that the LX50 as a J2EE system is competitive with Microsoft .NET on Dell hardware based on a value-offered basis. Also, CNET columnist David Berlind writes that the new server is more a bet on Java's success than an embracing of open source.

    Read Sun bets its future on Java and D. H. Brown Study Concludes That Sun Linux with J2EE is Competitively Priced With Dell-Based Microsoft .NET Server Platforms.

    Sun's launching press releases:
    SUN MICROSYSTEMS TAKES THE POWER OF SUN[tm] ONE TO ENTRY LEVEL SYSTEMS AND LINUX.
    SUN CEO SCOTT MCNEALY SHOWS DEDICATION TO OPEN SOURCE AND LINUX AT LINUXWORLD.

    Threaded Messages (27)

  2. This is great. I see two advantages to MS products, cheap and easy .. kind of like some women I know. MS has always done well in the Mom-and-Pop shops of the world. Java on the other hand it scalable, fault tolerant, robust, etc. It's getting easier, but it's not cheap. This is a step in the right direction.
  3. Why does everyone say Java isn't cheap? It is. If you use Unix and Websphere/Bea/etc and DB2/Oracle maybe not so much. But with MS you must have Windows and SQL Server and VS ... .

    The price issue is FUD. Not reality.
  4. I disagree. J2EE is not cheap. First, most implementations use WebSphere/BEA on Unix. Also, look at the development cost. Java developers average a lot more than MS developments. In some places twice as much. Also, to train your current staff to develop in J2EE is very difficult. You have Remote interfaces, Home interfaces, CMP vs BMP, etc. By the time you train them, you forgot what you wanted to build. I haven't see .NET yet, but I bet you can give someone a ".NET in 21 Days" book and they're off and running.

    J2EE wasn't meant to be cheap. It was meant for high avaialiblity, high reliability, high etc. etc. etc.
  5. First, most implementations use WebSphere ...

    That doesn't mean J2EE is expensive. Just that implementation.

    >Java developers average a lot more than MS developments.
    They usually do a better job. :) So up front costs maybe more. You get what you pay for. Actually, I am currently getting paid more for MS technogies. :p

    >Also, to train your current staff to develop in J2EE is >very difficult

    You think .Net is easy (well built apps are not)? J2EE can be easy too. If you hand code EJBs - probably tough and expensive. Why do that? Why even use EJBs? One doesn't need to do EJBs to do J2EE. If one develops Java apps like most MS (VB/ASP or .Net) apps then the cost will be the same.

    I have seen and used .Net. Want to whip crap out? Not too difficult. Do something good - There is a learning curve. I've used VB for years (MCP) and am a very quick learner. VS.Net is not just a install, read a book and do it for 99% of developers.

    >J2EE wasn't meant to be cheap
    Maybe via Sun and IBM and Oracle and Bea. But via JBOSS and Apache and ... it can be and is.
  6. I don't think there are any conflicts between high avaialiblity, high reliability, high etc. etc. etc. and easy to develop and use.

    Unix and J2EE world got to learn this lesson.
    Easy to use and develop are the buttom line.

  7. <Q>
    I don't think there are any conflicts between high avaialiblity, high reliability, high etc. etc. etc. and easy to develop and use.
    </Q>

    I would say this is true. I think you (If I am reading right) are wrong on who needs to learn. Java is all of these things. It can be made difficult. MS technologies are only part of this. Don't forget easy to maintain. MS technologies (current ones) are this too but most using them aren't doing it right. Not that Java doesn't have its fair share.


    <Q>
    Unix and J2EE world got to learn this lesson.
    Easy to use and develop are the buttom line.
    </Q>

    Why?

    Unix is and will be expensive - for the most part (Typically because of the box it comes on. Not the OS). It actually can be quite 'cheap'. But who cares. If one wants to pay for Unix they can. They don't have to unless they need the preformance - or do they.

    What does J2EE have to learn? Actually it is the FUDmungerers that need to learn.

    If you think J2EE is expensive because of EJB's and in comparison to MS technologies - think again. Compare apples with apples - as best can be done. Nothing currently in the MS world compares to EJB's. Nothing compares to the mirade of O/R mapping tools available in Java. Have you tried what is available in .Net? Not even close. With something like Hibernate and/or Castor and/or Glue - an excellent presistance/xml serialization/etc can be whipped out.

    They are easy to use and develop. Pick good tools. There are many to choose from in the Java world. I am using WSAD. Talk about simple.

  8. Did you notice the News item from Meta Group. It says that J2EE's complexity is hindering the platform. This supports my agrument that it's not easy. MS will come up with something that is. They always do.

    It may not seem hard to us, because we're J2EE developers, but give it to someone who isn't a J2EE developer. I have seen people with over 10 years of development experience spend a week to get a J2EE "Hello World" application to work.
  9. Yeah, I saw it. Do they actually do any developement? It is the FUD and the misinformation that might be hindering 'J2EE'. EJBs might be complex. J2EE isn't.

    For those spending a week to do anything. They will have the same fun with the same type of app in VS.Net. Java has its share of crappy tools. It also has great ones. Pick good ones.
  10. Yes, I ACTUALLY do development. J2EE development at that. EJBs are an important part of building a large enterprise fault tolerant system. They are complex and a lot of people have problems with them.
  11. Yes, I ACTUALLY do development...

    I meant does Meta? I figure you did.

    We do the same type of developement. We don't do EJBs. I have created them. Using a good tool - nothing to them.
  12. <
    Wow, you've created them... and with a toool. Wow. Nothing to them. Thats cool.

    So lemme ask you, when a CMT Stateful SB calls a stateless BMT bean what happens to the transaction context? If a stateless SB sends a JMS message which is picked up by an MDB, can the MDB inherit the tx context? What about the users credentials?

    How can you say "nothing to them"? Meta is DEAD on. The entire J2EE spec has become overly complex, confusing and academic. While we sit here and pontificate on the 12 best patterns for modelling a master-detail relationship MS is out there building a wizard.

    The Java Community must wake up and understand this is about writing software, not specifications.

    Dave Wolf
    The Scupper Group
    dave@scuppergroup.com_nospam
  13. Dave,
      No reason to be snotty (Well maybe you do). I didn't say I only used a tool. Thing is that is the only way for them to be simple. Most things are not as complex as you describe. So for those few things - OK, it is complex. So if a J2EE tool can't whip out EJBs how can MS create a comparible wizard?

    MS has nothing like EJBs. I've done COM+. It isn't. So compare the same things. What MS has won't do what you describe.

      You are right about writing software. We are doing it and not worring about specifications. And doing J2EE.

      Maybe the spec is Complex. I don't really need to worry about that. That is IBM's and Bea's and JBoss's and ... 's worry. But doing J2EE is not (for the most) part. Anything complex in J2EE will be just as complex in any other tool.
  14. <quote>
    MS has nothing like EJBs. I've done COM+.
    </quote>
    Well, they do have the equivalent of a stateless session bean which was originally run and managed under MTS and subsequently subsumed into COM+.
    Thre is an old article(dated May,1999) that have a in-depth comparison between MTS and EJB at http://members.tripod.com/gsraj/misc/ejbmts/ejbmtscomp.html.

    Regards,
    Hun Boon Teo
  15. Dave: "So lemme ask you, when a CMT Stateful SB calls a stateless BMT bean what happens to the transaction context? If a stateless SB sends a JMS message which is picked up by an MDB, can the MDB inherit the tx context? What about the users credentials?"

    Well, let's see:

    1) CMT SLSB's Tx context will be suspended before BMT SLSB is called
    2) No, MDB does not inherit client's Tx context
    3) MDB does not inherit client's EJBContext, hence, you do not have access to user credentials.

    Dave: "While we sit here and pontificate on the 12 best patterns for modelling a master-detail relationship MS is out there building a wizard. "

    Ant worked pretty well for us, better than any wizards. This is especially true if you are interested in consistent builds.

    Dave: "The Java Community must wake up and understand this is about writing software, not specifications."

    IMO, the specs is one of Java's major advantages. This is what gives you the confidence to use software from an innovative but not necessarily major vendor.

    -- Igor

  16. Igor,

    My questions about tx's and security context were never meant to be answered. They were rhetorical.

    What does Ant have to do with design patterns for master detail? Trust me I'm a huge Ant fan. JEdit's Ant integration is glorious.

    Yes I agree specs are great. I worked for many years for a container vendor so I am very familiar with them. However my point is simply the specs have gotten way too complex and way too confusing for the average developer to every understand. Take a gander at the questions we get in the tss.com forums and you will see many of the most basic J2EE constructs stupify many many developers.

    Dave Wolf
    The Scupper Group
    dave at scuppergroup dot com
  17. Dave,

    The answers were given just to illustrate the point that J2EE is not really that complex. IMO, the level of complexity is quite reasonable considering the complexity of the tasks the platform solves.

    I do agree with you that specs are not an easy read (there are some good books though). But to say that some spec is too complex, we perhaps need to present an idea of how things could be done in a simpler/better way.

    -- Igor
  18. With the success of JBoss, open source deveopers and hackers have access to a good standard J2EE platform. The influx of open source developers being exposed to EJB should help to increase the pool of EJB programmers and demysitfy the intricacies of EJB.
  19. I think J2EE can be cheap. We are using an entirely open source solution. JBoss, Tomcat, and the other usual suspects can provide a $0 software solution that is fully J2EE compliant. A developer with a java background can be up and running with J2EE in a very short time. Tools like Eclipse, Ant, and Xdoclet can be combined to automatically generate all of the interfaces and deployment descriptors, take care of packaging and deployment, and provide a debugging environment. This lets developers focus on solving problems rather than worrying about infrastructure. I’ve rarely seen anyone develop quality applications just by buying a “Learn Blah in 21 days” book.
  20. JBoss (j2ee container)
    + Apache (web server)
    + Tomcat (servlet runner)
    + Ant (configuration tool)
    + Cactus (automated testing)
    + JDeveloper or JBuilder lite (ide)
    + MySql (database)
    + linux (OS) = 0$
    + jdk 1.4 or JRockit (jvm)

    Of course you need to train your people to use these technologies and hardware costs money, but its possible to do some incredible things with Java very cheaply!!

    Java rocks folks... it just does.
  21. The time (ie COST) taken to architect, develop, test and install any non-trivial system properly on any platform will frequently be far greater than the cost of the machinery needed to execute it.

    If I went to my management and could prove, "Buy Websphere [or whatever] it will save my team 10% development test and admin time" it would be bought in a flash.

    So, .Net, J2EE, Websphere, Jboss -- whatever. The most expensive part of the process are the people involved.

    I believe you will get better results for the time being out of J2EE just because there are more people available with a greater depth of experience with that technology and a greater amount of support materiels than .net, not because JBOSS is free.

    regs
    scot.

  22. <Q>
    So, .Net, J2EE, Websphere, Jboss -- whatever. The most expensive part of the process are the people involved.
    </Q>

    Agreed. (Usually)

    So why not save money where you can if you can? Many are in the position of needing to do this. They have to cut where they can. Also, if you are a consultant/contractor wouldn't it be better [for you and probably for the client] if the client spent money on you and not on technology (or at least less)?
  23. <Q>So why not save money where you can if you can? Many are in the position of needing to do this. They have to cut where they can. Also, if you are a consultant/contractor wouldn't it be better [for you and probably for the client] if the client spent money on you and not on technology (or at least less)? </Q>

    Not if the technology or product was so complex and difficult to learn that the expensive people took more time to implement with that technology or product, and hence it cost alot more money. Saving $N on technology where that could cost you $N X 10 in development, deployment and maintenance isnt cost effective. You need to look at the total cost of ownership.

    Dave Wolf
    The Scupper Group
    dave at scuppergroup dot com
  24. <Q>Not if the technology or product was so complex and difficult to learn that the expensive people took more time to implement with that technology or product, and hence it cost alot more money. Saving $N on technology where that could cost you $N X 10 in development, deployment and maintenance isnt cost effective. You need to look at the total cost of ownership.
    </Q>
    I agree.

    And most don't look long tem. They look at up front costs. "How fast can we generate code". Not - "What will it cost to maintain and modify"

    Java is not that complex. No more than .Net. Unless you code Java with notepad. Try .Net with notepad then compare. Can't toss in EJBs because .Net only uses stateless stuff so compate it to JDO or Hibernate (Actually I would say Hibernate is better than what .Net has to offer). So development environments being equal what left is platform/OS and supporting software. These cost can add up. Many shops are moving to single servers because it cuts back on employee costs.
  25. Most IT shops these days base decisions on TCOs.

    There is some merit in Dave Wolf's argument that the specs in Java have become rather complex. Well that's how most evolved societies operate. Take any spoken language and compare it with the same language in historical terms. As time progresses, the evolutionary processes adopt increasingly complex features into the language for good reason. I use Java and J2EE (w/c is basically a framework) interchangeably.

    The real problem IMO is the quality of people used to build any system. It takes more to be a good Java developer than a MS developer. Any bloke can term themselves a MS/.NeT developer with relative ease. The quesions facing the management is how good these resulting systems would be? I believe .Net is an attractive proposition owing to its simplicity but it is unproven how good these systems can be to support large scale infrastructure.
  26. I see two advantages to MS products, cheap and easy .. kind >>>of like some women I know



    ouash !!!

  27.  I agree this a step in the right direction ; but, it is no giant leap for PC-kind. Any one with a little know how could get a good box like the LX50($2800) for $1300 and then put x86 Solaris 8 on it. It is not easy to see SUN's motivation behind its waffling on development for
     x86 Solaris 9.
     If it is SUN's strategy to go after the low end, then
    x86 Solaris is one of the best weapon's SUN has. But,don't be quislings and price it like the B2 bomber so you can build 4 ,while the Mongol hoards over run your factories.
     If you want to put Solaris in the hands of Linux users,
    give the download away and make sure it installs like
    Red Hat. Scott McNealy keeps raving how SUN can do the best supply chain economics. Well, get that LX50 down to $900 bucks. Go to Taiwan , if you have to.
     Once Linux users see that Solaris and Linux are cousins with the same BSD roots and you can run Gnome and KDE on Solaris, so that you hardly notice the difference(except for performance), then SUN will have bragging rights again.
     And, maybe,they can save some lost souls from the Leviathan's .NET.
  28. Is the entire Sun ONE stack included in the price?

    I can't see anywhere that is says that.

    It says that it come with Sun One ASP and that the rest of the stack "will be running soon" on this configuration.

    That does not tell me that the rest of the configuration is included in the price.

    Thanks.