Discussions

News: Java taken for granted as the defacto standard

  1. Java taken for granted as the defacto standard (83 messages)

    Despite no longer being the "next big thing," Java has finally achieved one of the highest honors the tech industry can bestow: It is taken for granted as part of the infrastructure on which many companies depend. A newsfactor article provides a high-level overview of recent developments in Java, the JCP process, .NET, and new directions for the language.

    Read The Future of Java.

    Threaded Messages (83)

  2. The article starts with an interesting point about how Java isn't seen hyped up much any more. It's funny how the media spends so much air time on the latest buzzwords and hype. For example, web services are discussed in media so much, you'd think that everyone and their mother are using them, or that the WS market is bigger/more important than the enterprise development market - when in fact the integration market (which is what WS are for) is a subset of the enterprise development market.

    On TSS we strive to focus on the important bread-and-butter J2EE news and content that matters to J2EE professionals, and delve into WS and other hype driving articles only where there is something new and useful to be learned from it.

    Floyd
  3. Music to my ears[ Go to top ]

    I read the article earlier when it showed up next to another similar article concerning Scott McNealy's "birthday address".
       Mr. McNealy gave several reasons why SUN would rebound from its doldrums, chief among them the fact that SUN continues to heavily invest in R&D. But the other good reason to be bullish with SUN and all other significant Java-based vendors is because of this article --- the article is laughable for the reasons the Floyd Marinescu mentions (ie. media can't get over all the hype), but in the end, the article is right!

       Java is now a defacto standard in companies and technology!

       Feels good to say that! It indicates that we will be able to leverage our technical skillset for many years to come.

    Larry.
  4. Music to my ears[ Go to top ]

    Just to be clear, I didn't say that the article itself is laughable, I was agreeing with the article's point on java not being a hyped headliner anymore, and I explained why it is unfortunate that the media industry operates the way it does.

    It definitly feels good to say java is the defacto standard, Mr. Ellison. :)

    Floyd
  5. Stock Price[ Go to top ]

    Now if only the stock price would just get back up there...
  6. It still is dubious how the present situation fares well for the future of Java. Let's face it -- J2EE is unnecessarily complicated. Make that extremely complicated. To the point where it's becoming a repellant for many corporations.

    Now, how can that be good for the platform? And more importantly, what are we doing to alleviate the problem?

    I really deeply dislike .Net, but I nevertheless feel threatened by it. If things continue to be this complicated with J2EE, we'll have no choice but to join the evil empire. I'd hate to see that happen, but don't know how to avoid it at this point. Yeah, I know, they've just announced new tools coming out to help alleviate stupid shortcomings of the J2EE platform, but they've been announcing such tools for years now. And each release was a major disappointment.

    Alex
  7. Interesting Point[ Go to top ]

    I've never really taken the notion that Java is "too difficult" very seriously, but that doesn't mean that you are wrong.

    However, it would be nice to hear from some middleware vendor employees about the topic. For example, the engineers who in my opinion have to deal with the most difficult programming of all -- the making of a commercial J2EE-compliant EJB Container and all it's intricacies.

    To me, it seems safe to say that whatever you need to learn with Java APIs, you can learn if you're given enough time. None of the APIs strike me as misleading, confusing, or incomprehensible. For the most part, it's the architecture that you are forced to work with that causes the problems, not the language.

    Larry.
  8. Interesting Point[ Go to top ]

    I've used alot of aspects of J2EE, including JSP, Servlets, Custom tags, EJB, JNDI, JAXP, JDBC, and some JMS. Yes, when you consider all of the technologies, there's alot of them. But to say that J2EE is inherently complex is an unfair criticism.

    The platform can be as simple or complex as you wish. If you have a smaller application, just use JSP, Struts, and JDBC and it's as simple as you can get. As simple as .Net. In fact, based on your faith in Struts, maybe even simpler.

    And for enterprise class applications, you will most likely require more technologies, thereby increasing the complexity. But realize that this is your choice and you should use *any* technology based on need.

    And one tip I would offer is to choose your toolset wisely. Just because something is free doesn't mean it's the best choice. After all, a $1000 tool investment only takes 20 hours @ $50 / per hour to recoup the cost. On a 10 week project, that's only 2 hours per week.

    There are some technologies in J2EE that have not caught on. But like with any platform or framework, your job is to simply understand which of them to stay away from and which of them provide a great bang for the buck.

    And please consider that most softare projects fail because of non-technology related problems such as bad requirements, wrong methodology, etc. In my experience, software engineers are almost always capable of solving the hardest technical problems. But ask them to understand how to model income tax software and that's another challenge.

    My 2 cents ... joe
  9. When to choose EJB[ Go to top ]

    Why is there a mindset in the J2EE community that you either write all your systems completely in EJB or you don't use EJB at all.

    We tend to mix POJO and EJB, for example the E-commerce site is written in JSP and POJO since all the business functionality is specific to the site, however the companies general ledger is written in EJB because that business logic is shared across several applications (some of which are written in POJO and some which are written in EJB) allowing us to have a common General ledger.
     
    This is pretty much my understanding of how best to apply EJB, maybe I'm missing something, anyone care to comment?
  10. When to choose EJB[ Go to top ]

    Why is there a mindset in the J2EE community that you either write all your systems completely in EJB or you don't use EJB at all. <

    I'm not sure if there is, is there? The debate seems to center on *Entity* beans. session and message driven beans are usually non-contreversial, except for small applications.

    My current favored architecture uses stateless session beans and message driven beans for application logic, together with POJOs for the business model and DAOs + Hibernate for persistence.
  11. When to choose EJB[ Go to top ]

    I'm not sure if there is, is there? The debate seems to center on *Entity* beans. session and message driven beans are usually non-contreversial, except for small applications. <

    So what is the point then of EJB's altogether then, Entity EJBs are the most powerfull part of EJBs, may as well just use plain old RMI objects and JMS calls sitting above a plain old DAOs.
  12. When to choose EJB[ Go to top ]

    The container managed transactions and security make local stateless session beans a nice thing to use even in small projects. Message driven beans make using JMS easy. With EJB 2.1, you can even set up your web service end points with EJBs.

    And I firmly disagree with the statement that Entity EJBs are the most powerful part of EJB. Session beans provides useful abstractions and remotability. Entity beans provides a persistence system that could just as easily be provided using any number of ORM tools like JDO or Hibernate. No one recommends exposing Entity beans directly which eliminates the need to have container managed transactions and security (a session bean in front of you already handles it). ORM tools can provide all the power (and more) that container managed persistence and relations provide. So why not replace all the overhead of the container with a lightweight tools, but use the benefits of the container where they can actually help out?
  13. When to choose EJB[ Go to top ]

    I agree.

    It is ismple, use a tool when you need something that the tool offers.
    Use EJB when you need transparent object distribution, declarative security or transactions.
    If persistence is all you need, find a better tool.

    Mileta
  14. Interesting Point[ Go to top ]

    The platform can be as simple or complex as you wish.


    I don't understand why is this choice a good thing? If something could be made simple, why would you wish to make it complex? Unless you're a raving lunatic, why wouldn't you want to go with the simplest possible solution?

    Alex
  15. Interesting Point[ Go to top ]

    The platform can be as simple or complex as you wish.


    >I don't understand why is this choice a good thing? If something could be made >simple, why would you wish to make it complex? Unless you're a raving lunatic, >why wouldn't you want to go with the simplest possible solution?

    The simplest possible solution can be quite complex depending on the problem.
    And that's what people have been talking about, choosing the correct level of complexity.

    In the recent past many projects chose EJB because of the hype not because it was the correct technology to solve the requirement.
    That practice gave EJB as a whole a bad name as a bloated overly complex technology.
    Personally I've looked into EJB but never yet had a chance to use it in a reallife environment.
    Do I miss it? Not really. Sometimes I might have been a bit cleaner using EJBs for data access instead of regular beans but always the overhead would have been too much (I've not worked on large distributed applications, only applications running on a single server).
    So I use Servlet/JSP/JDBC (in regular beans) instead which works well.

    Were I to need a system running across several servers EJB might be an appropriate solution.

    The same can be said about other technologies. If you use them just because you can and not because they're the best solution for the problem at hand you're probably using them for the wrong reasons and something simpler might suffice (though you can have picked the correct technology anyway of course).
  16. |
    |is unnecessarily complicated
    |

    I see plenty of assertions to this effect - but very few details and even fewer concrete ideas for improvement.

    Its far too easy to criticise when no ideas are offered as substitutes.

    -Nick
  17. I see plenty of assertions to this effect - but very few details and even

    >fewer concrete ideas for improvement.
    >
    >Its far too easy to criticise when no ideas are offered as substitutes.

    I'm not in the business of building computing infrastructure. I'm in the business of USING computing infrastructure. Knowing that, why should I be bothered with offering ideas for improvement as substitutes?

    If I'm using the road systems in my country, and I find them to be bumpy and full of potholes, is anyone expecting me to offer ideas for improvement? No, because the only course of improvement is to fix the damn thing!

    Same is with J2EE -- it sucks, so please fix it! It's not my job to do it. I, as a consumer, have the full right to complain that the product you're offering me is substandard. If you can't deal with such criticism, maybe you're in the wrong line of business.

    But the way this whole thing works is by consumers complaining and vendors responding with fixes. Otherwise, there won't be any progress at all.

    Being complacent won't lead us anywhere.

    Alex
  18. But, Alex (we have been through this before),

    Unless you can actually back up your judgements, how can anyone possibly take them seriously. Not being able to justify your criticisms (or even describe them) just illustrates a lack of understanding of the problem and the technology.

    |
    |But the way this whole thing works is by consumers complaining and vendors
    |responding with fixes.
    |

    And the vendors are supposed to guess what you think is crap?

    -Nick
  19. Unless you can actually back up your judgements, how can anyone possibly take

    >them seriously. Not being able to justify your criticisms (or even describe
    >them) just illustrates a lack of understanding of the problem and the
    >technology.

    Oh, I can justify and describe my criticisms, but it would take a lot of space.

    Besides, I'm not in the business of understanding the technology. I'm in the business of USING the technology.

    Same as I can use my cell phone without having to understand how that technology works, I'd like to be able to use J2EE without having to understand the technology.

    It just so happens that I understand perfectly well how J2EE technology works (having 15 years of software development experience and more than 7 years full time Java experience). However, I'm not impressed. I know that they can do so much better.

    Let's take the simplest possible example -- Java Mail API. It consists of only four packages (I think it is probably one of the simplest API in J2EE):

    1. javax.mail
    2. javax.mail.event
    3. javax.mail.internet
    4. javax.mail.search

    Now, the question is, why would I want to use this API? The answer is simple -- I'd like to use it whenever I have to send an email from my application. There are valid business reasons why we'd need to dispatch an email at certain points in our application processing. And these dispatching points are governed by the business logic (as is the content and the destination of email messages).

    OK, so now that we've established WHAT is it that we're trying to do, let's look at HOW are we to do it:

    We first need to get the system properties

         Properties props = System.getProperties();

    Then, we need to set the values for the host in the properties

         props.put("mail.smtp.host", host);

    We then need to establish the session (I'm describing the simplest possible way of sending an email here)

         Session session = Session.getDefaultInstance(props, null);

    Following that, we need to TRY to instantiate a message

         Message message = new MimeMessage(session);

    Once we do that, we then have to set the from, recipient, subject, text, sent date attributes. Finally, we send the message

         message.setFrom(new InternetAddress(from));
         message.addRecipient(Message.RecipientType.TO, new InternetAddress(to));
         message.setSubject(subject);
         message.setText(text);
         message.setSentDate(new Date());
         Transport.send(message);

    Now, the question is, WHY do I have to worry about such administrative tasks such as system properties, session, mime messages, and so on? All I want to do is simply send a message to the recipient, indicating who is the message from and when was it sent. I'm expecting the underlying system to do the legwork for me, instead of me having to fret over such excrutiating minutia.

    So, in the absence of such service, I was forced to design and provide my own Mail Proxy. I was forced to use design patterns and do the whole song-and-dance charade. I know perfectly well how to use those things, how to hide the complexities behind the facade etc., but the bottom line question is: why should I be forced to do all the legwork when using this stupid platform? Why couldn't the creators supply all those design patterns with the platform?

    The above, to me, is a hallmark of a lousy design. Granted, it's an extremely mild case of lousiness (I've used it strictly for its brevity), as elsewhere in J2EE platform we encounter much more blatant disregard for supporting the end user's goals. And that's why this platform really sucks, and the vendors must make an effort to make it easier to use.

    Now, I know that there are people on this forum and elsewhere who love it just the way it is, warts and all. There are people who love it when it gets unnecessarily complicated. They see that as a challenge to them, which they enjoy solving. I know that, because I used to be one such geek. But, I have moved on, I've matured, and realized that it's not about toying around with sexy new gadgets, it's about solving business problems.

    Alex
  20. One man's facade is another man's junk[ Go to top ]

    why should I be forced to do all the legwork when using this stupid platform? > Why couldn't the creators supply all those design patterns with the platform?


    If a platform is supposed to appeal to a wide range of people, it must provide low-enough level access so that other people can build more specific solutions on top of it. Maybe your facade is exactly what you need, but it wouldn't work for me, because I have slightly different requirements. Why should Sun (or the Java Community) spend a ton of time creating domain-specific abstractions when they limit the audience, rather than broaden it?

    Of course, higher level, domain-independent abstractions are the holy grail. One of my old managers used to ask me - how come I can't just program it in Visio? The silver bullet is always a inflexible lowest common denominator solution. It's ironic, but in removing complexity so that you can focus on your business requirement, I just made it impossible to solve your requirement because it is too specialized.

    Typically there will be higher level open source solutions built on top of J2EE that you can use in your project. If not, build your own.

    Using your analogy, J2EE is designed for people who want to build cell phones, not use them.
  21. Continued[ Go to top ]

    Hi Alex,

         I have to say that I completely understand your demands and critique on J2EE. Building on Eric Pederson's comments above, I would think that the reason why J2EE can become unwieldy is because, by definition, the Java language and its APIs are not intended to provide finished products that could satisfy every end-user there is.
         Having said that, I don't think that what you are saying is "Make every end user happy" -- I think what your argument points out is how difficult it is to build a codebase based on specific requirements from Manager "ABC" upon an abstracted implementation framework like J2EE.
         Again, by definition, this kind of work cannot possibly be made easier because it assumes nothing about the underlying infrastructure nor anything about the overlying requirements. In my opinion, the only way to achieve the demands that you have put forth would be to use a different programming langauge implementation, such as PowerBuilder or Delphi.
         Why? Because PowerBuilder or Delphi are tools that have streamlined/standardized the communication paths and data constructs that these products use. Coming back to my comment in my previous email, this is why I believe that only through some internal "hard-coding" that binds different components together can a product really become "intelligent" enough to have some kind of built-in capacity to handle the situations you mention. The JavaMail example is well said --- the reason that JavaMail will not handle sessions for you automagically is because the JavaMail API does not assume to know how the concept of a Session object is used between different eMail products. However, if there were a product that absolutely knew that it would be interfacing with, for example, MicroSoft Outlook, then I guarantee you that coding a mail application with this imaginary product(!) would fulfill your wishes.
        
    -Ted
  22. Continued (Mark me as noisy)[ Go to top ]

    How many "J2EE is too complex" does theserverside need?
  23. One man's facade is another man's junk[ Go to top ]

    If a platform is supposed to appeal to a wide range of people, it must provide

    >low-enough level access so that other people can build more specific solutions
    >on top of it. Maybe your facade is exactly what you need, but it wouldn't work
    >for me, because I have slightly different requirements.

    So? I don't know why people in general tend to think in extreme black-and-white terms. If I say that I'd like to see high level facades and proxies, why do you automatically jump at the conclusion that I want to see the low level REPLACED by the high level. Nobody is talking about replacing anything. Low level will always stay low level, and you can play with it until the cows come home. Be my guest. But don't be an obstacle to my goals, just because you misinterpret my need for the high level stuff as a threat to your need for the low level stuff.

    Just because I may decide to offer some high level APIs doesn't automatically mean that I've decided to hide all the low level ones. Low level APIs remain accessible for people who need them.

    What's so wrong with having both low AND high level APIs?

    You should learn to think in a less muddled way, and see change as an opportunity, not as a threat. I hope I've managed to convince you here that by allowing high level APIs into the J2EE platform, we're not in any way sacrificing low level ones.

    >Typically there will be higher level open source solutions built on top of
    >J2EE that you can use in your project. If not, build your own.

    This is exactly the core of the whole problem! Thanks for bringing this up.

    My exact point is that I don't want to be forced to build Mail Proxy patch on top of J2EE. The point I'm trying to make is that J2EE MUST come with a Mail Proxy out of the box (as well as many other high level objects that mask the underlying complexity). That Mail Proxy should be preloaded with the least common denominator assumptions (statistically speaking). If I don't like those, it would be easy enough to change them, or to bypass the proxy altogether.

    I also don't want to be forced into using those crappy Apache frameworks, which are no better than the present J2EE drivel.

    >Using your analogy, J2EE is designed for people who want to build cell phones,
    >not use them.

    Entirely not true. In this analogy, cell phones are meant for carrying the information exchange (i.e. a conversation, or a text messaging exchange). What we're doing when using J2EE platform is engaging in the information exchange. I don't want to build cell phones, I want to send soft information over the channel.

    Alex
  24. my mistake[ Go to top ]

    Alex,

    I am sorry I took you for one of these impractical theorists.
    I did the same mistake as many others, thinking that you only wanted some magical high level framework that could do everything.

    Both high level *and* low level stuff is the way to go.
    Of course.

    My sincerely apologies
    Rolf Tollerud
  25. One man's facade is another man's junk[ Go to top ]

    Alex,
    Do you think those high level portions you seek should go in the J2EE APIs themselves or should they be a part of a given vendor's implementation of those APIs? I see the high level convenience portion to be more the domain of the tool vendors and the app server vendors, should they so choose.

    Cheers
    Ray
  26. One man's facade is another man's junk[ Go to top ]

    Do you think those high level portions you seek should go in the J2EE APIs

    >themselves or should they be a part of a given vendor's implementation of
    >those APIs? I see the high level convenience portion to be more the domain of
    >the tool vendors and the app server vendors, should they so choose.

    Ray,

    It doesn't really matter to me, so long as I get a product that's going to support my goals. To stick with the cell phone analogy, the fact that each cell phone comes with a 'Send' button is a life saver for me, because it allows me to use various phones without having to complete a two week course. But whether that 'Send' button is there by the virtue of some standard specs prescribed by the hypothetical 'cell phone committee', or by the virtue of the cell phone manufacturers being smart enough to know that it will make their product more desirable, doesn't affect me in any way.

    If cell phones today didn't come with the 'Send' button, but expected me to perform a very complicated and convoluted ritual before I could establish a connection, you would hear me complaining to the bitter end (same as I'm complaining about J2EE here).

    Alex
  27. One man's facade is another man's junk[ Go to top ]

    What's so wrong with having both low AND high level APIs?

    The problem is that java's architecture doesn't allow it. There is no efficient way to build complex OO heirarchies in java without incurring severe performance problems and induce brittleness. J2EE tries to create an abstract operating system on top of an existing OS. When it was created, many things did not exist, or behaved differently, for example, on Windows that would be needed. The JavaMail API is an example of trying to enforce the RFCs onto divergent platforms. In the end, they had to scrap any underlying mail support and build the mailer functionality from scratch. And then proceed to implement all the RFCs that mail servers have evolved to overcome divergent tasks. The end result? A mess that is bloated, and in the end, no easier to use than:

    exec("sendmail %s", long_list_of_args)

    You have EJBs, which try and fail to deal with such incredibly divergent things as transaction state, network transparency, and data persistence. Why? Because you keep running into cases where persistence has to be within a transaction, or remote objects have to trigger messages. These things are easy to do with pipes, semaphores, file locks, etc. on a low level, but ascii pipes can't handle
    complex objects.

    So you wind up with things like web services. Anyone who's ever been on an email list or clicked "notify sender" in outlook has used the equivalent of web services with SMTP. Its not fancy. Port 25 is open on almost as many networks as 80. But I'm getting off topic.

    The point is, that instead of building Rube Goldberg contraptions (like J2EE App Servers) around our objects to get them to interoperate, we should just build bigger pipes.

    In the case where functionality may not exist in some cases, it can be implemented (like JavaMail), but implemention functionality should be separated from interface API.
  28. |
    |Besides, I'm not in the business of understanding the technology. I'm in the
    |business of USING the technology
    |

    And if one plans to use a technology without understanding it, then its little surprise that it results in a lot of frustration. You should read about leaky abstractions

    |
    |Same as I can use my cell phone...
    |

    Here we go again with a piece of hardware. Hardware != software.
    However, even in this example, you DO have to have an understanding of the underlying technology. If no-one needed to understand anything about mobile phones, then there would be floods of complaints that they "stop working" underground and that US phones "dont work" in Europe?

    |
    |So, in the absence of such service, I was forced to design and provide my own
    |Mail Proxy
    |

    So why dont you post it so we can check it out? Maybe the JCP would be very interested. I'm all for improving the api's.
    (BTW, why didnt you use JNDI to get your session instead? Some of the "administrative tasks" WOULD have already been done ... by an administrator...)

    -Nick
  29. Sorry Nick, but I'm with Alex on this one.

    The fact that he used a cell-phone as an analogy is not important. That it is hardware rather than software is not the relevant issue. That it has certain usability features that people take for granted is the relavant point. (Besides, cell phones are software. That the underlying hardware differs is not really the point, especially when talking about a language like Java. :-) )

    Your other comment, about using technology without knowing how it works, is the core of your disagreement.

    Your point, if I interpret you correctly, is that you must know about the technology to use it properly. I agree with that in principle.

    However, Alex's point, if I interpret him correctly, is that if he's just paid a lot of money for a server, or has just spent time getting to know all these APIs, then he should not have to know "too much" about what's going on under the hood.

    As I recall the motivation behind the J2EE APIs it was to build "scalable, reliable infrastructure, in which the "plumbing" work is done for you and you can focus on business logic, where value is really added." The whole point was to commoditize the non value add. In that regard, J2EE has failed quite spectacularly, IMHO. Look at all the books on bitter J2EE experiences, and how to do it properly etc. We haven't solved the problems, we've just moved them around and given them different names. I still have to worry about database concurrency and avoiding bottlenecks, but now I have to do it from 2 levels removed, which makes it harder.

    I agree you should know the pitfalls and possibilities of any technology before you use it, but I think you need far too much expertise to be able to deliver solid J2EE systems, when judging against the stated goal of that technology.

    Just my 2c worth.

    Chz

    Tony
  30. And if one plans to use a technology without understanding it, then its little

    >surprise that it results in a lot of frustration.

    Absolutely not true. I use plenty of technologies that I absolutely don't understand, like telephones, faxes, microwave ovens, TV sets, cars, banking machines, even refrigerators, but I'm not experiencing a lot of frustration when using those products. The only time I do experience a lot of frustration is when using computers. And the frustration when using computers stems from the fact that I need to understand in depth how those beasts work. And I feel it's a royal waste of time to try and understand something so trivial and insignificant.

    Why is it that I only need to understand how a computer works in order to use it? How come I don't have to understand how a car works before I can use it?

    >You should read about leaky abstractions

    I read it, and it's an unbelievable pile of bullshit! Who is that guy, and what does he think he's talking about? Again, such a load of false alarm crap.

    Let me explain something: it seems that 99% of the people who work in software arena suffer from this delusion which causes them to confuse things that are PROBABLE with things that are POSSIBLE. Many, many, many things in this life are possible. But just because they are possible, doesn't mean that we should go out of their way to prepare for them, and to do everything possible to handle them. However, not that many things in reality are probable. We, software developers, are in the business of handling things that are probable, not possible.

    Like, that guy talking about 'leaky abstractions' (what a weird term, by the way!), mentions how TCP is not actually that reliable, because although it guarantees the packet delivery, what if your pet snake chews through the network cable! Come again? What kind of drugs is he on? What is the probability of a typical network user having a) a pet snake, and b) having that snake chew through a cable?

    Notice how, throughout the entire document, he keeps repeating the keyword 'sometimes'. This is a give away that he is under the strong delusion mixing possible with probable. Yeah, anything's possible, pal, but it doesn't mean that we must address each and every far fetched possibility that comes to our overexcited minds.

    For example, he wrote:

    >And while these great tools, like modern OO forms-based languages, let us get
    >a lot of work done incredibly quickly, suddenly one day we need to figure out
    >a problem where the abstraction leaked, and it takes 2 weeks.

    Notice how he says 'suddenly one day'? How likely is that day to occur? That's the key question. If it's more likely to occur once in a blue moon, why should we completely abandon all the benefits of the abstraction just so that we would be able to handle a 'once in a million' hypothetical occurrence? OK, if such thing indeed does finally occur, I don't mind spending extra 2 weeks on fixing it, because I have more than saved up my time thanks to the abstraction I'm using.

    >Here we go again with a piece of hardware. Hardware != software.

    Untrue. Both hardware and software are products, meant for people to use them. I don't see how are they different. Besides, plenty of hardware products today are only thinly veiled software.

    >However, even in this example, you DO have to have an understanding of the
    >underlying technology. If no-one needed to understand anything about mobile
    >phones, then there would be floods of complaints that they "stop working"
    >underground and that US phones "dont work" in Europe?

    I disagree. Let's look at cars, for example. I don't need to understand how cars work in order to use them. So, if I go to England and start driving there, I'd be freaked out because they drive on the 'wrong' side of the road. So, I'd have to adjust my driving. But, in order to accomplish that, I wouldn't have to learn anything about how cars work.

    >So why dont you post it so we can check it out? Maybe the JCP would be very
    >interested. I'm all for improving the api's.

    I mean, how hard do you think would it be to write a Mail Proxy? Just because it didn't occur to them to do it, doesn't necessarily mean that it's a rocket science. They are incompetent, true, but not in the sense that they wouldn't know how to write a Mail Proxy. They are incompetent because they are not capable of realizing that their customers do need such a thing as Mail Proxy.

    >(BTW, why didnt you use JNDI to get your session instead? Some of
    >the "administrative tasks" WOULD have already been done ... by an
    >administrator...)

    Again, your level of misunderstanding is simply stunning. How would JNDI alleviate the need for administrative fiddling? My intention is not to even be aware of such a thing as 'session'. Why should I care about such stupid thing as session, when all I want to do is send an email? The very fact that I have to mention a session in a segment of code that deals with business logic and business content belies the utter incompetence of the creators of that framework.

    Whenever I'm dealing with business content and business logic, that's the only thing I want to see in the code. Anything else is something to be frowned upon. Any administration and configuration activity at that point is pure noise, something that pollutes the clarity of my business logic, and should be therefore hidden away. Consequently, such things should not leak into my business code (and note here that I'm talking in the PROBABLE, not POSSIBLE mode). Most likely, when I want to send an email, I just want to specify the recipient, the subject line, and the content. Everything else (the date sent, the sender, the type of message, the session, the protocol and so on, is assumed).

    Alex
  31. J2EE is unnecessarily complicated?[ Go to top ]

    "J2EE is unnecessarily complicated"?
    Maybe YOUR DESIGN is unnecessarily complicated?

    Oh, I have to write a 'Hello, world' application. Everybody says that EJBs are cool... how can I use Entity Beans in it?

    The question is not what CAN we use, but what SHOULD we use, isn't it?
  32. J2EE is unnecessarily complicated?[ Go to top ]

    "J2EE is unnecessarily complicated"?

    >Maybe YOUR DESIGN is unnecessarily complicated?
    >
    >Oh, I have to write a 'Hello, world' application. Everybody says that EJBs are
    >cool... how can I use Entity Beans in it?
    >
    >The question is not what CAN we use, but what SHOULD we use, isn't it?

    No it isn't! The question is what MUST we use. And because my job is to provide enterprise wide software solutions, I MUST use J2EE. There is no alternative.

    This makes me unhappy, as J2EE is a substandard platform. Yet, I have no choice other than to grumble and complain.

    But please don't try to fool me into believing that J2EE is good and easy to use, when it's obvious that it plainly isn't.

    Alex
  33. J2EE is unnecessarily complicated?[ Go to top ]

    Alex,
    In all of your posts, about all you say is that J2EE sucks, to paraphrase. And while that is certainly a valid point of view, why don't you tell us what sucks specifically and why it makes your job so hard and what about it you don't understand. When you say 'enterprise wide software solutions' - what sorts of applications do you mean (enterprise applications can cover a very wide range)? What tools are you using? J2EE is a nice collection of APIs - not every one is the right thing to use for every job and careful decisions should be made about when to use what piece.

    And since 'enterprise wide software solutions' can in fact cover such a wide range of possibilities and interactions, there are portions of J2EE which, while they may seem complicated and hard to use to you, make certain jobs much easier. Of course, if you don't need those components (for example everyone's favorite whipping boy - entity beans) - don't use them. The beauty of J2EE is that there is always more than one way to approach a problem.

    If you are being forced to use J2EE against your will, ask questions instead of complaining. Few, if any, of us are sitting on the J2EE spec committee. We can't re-write the specs, but perhaps there are those who can help you use the existing ones more efficiently and in a way that will allow you to keep the hair on your head.

    Cheers
    Ray
  34. J2EE is unnecessarily complicated?[ Go to top ]

    In all of your posts, about all you say is that J2EE sucks, to paraphrase. And

    >while that is certainly a valid point of view, why don't you tell us what
    >sucks specifically and why it makes your job so hard and what about it you
    >don't understand.

    Ray,

    I thought it was self-evident. What you're saying here is that basically you think that J2EE is quite simple. That's admirable. However, returning to your questions I must say that it would require me to write a book on things that suck in J2EE. So it's not going to be very feasible for me to explain all the aspects where J2EE sucks.

    Furthermore, it's important to stress that there isn't anything about J2EE that I don't understand. I have 15 years of software development experience, I've worked with Java full time since 1996, and the language and the platform hold very little secrets from me. I also teach Java and J2EE at the local colleges, so I have plenty of experience using it as well as transferring my skills to others.

    Now, on to the crucial question: why J2EE makes my job so hard? Contrary to your assumption, it doesn't make my job hard because I don't know how to use it (as I told you, I do know very well how to use it). It merely makes my job hard because it expects me to invest way too much time into making trivial things work. Obscenely copious amounts of time are required in order to make this thing function. I have to sacrifice the time I would have otherwise spent on more important things (such as working on the business logic), just so that I can serve this stupid machinery. That's what I'm complaining about, and that's why I'm saying that J2EE sucks. It is precisely because I know that this platform can be made to be so much simpler to use that I insist that we complain and demand that vendors simplify it.

    >When you say 'enterprise wide software solutions' - what sorts of applications
    >do you mean (enterprise applications can cover a very wide range)?

    I mean those sorts of applications that cover a very wide range. Everything integrates with everything else. Web based apps must integrate with legacy apps, and the two of those must integrate with ERP apps. In addition, all three must integrate with several 3rd party apps (vendor and supplier integration). On top of that, there are workflow and groupware and document management apps -- they also need to be integrated. And so on, and on, ad nauseum. And the only platform of choice that can accomplish all that is J2EE. I can't help but use JMS, JCA, Java Mail, JNDI, etc. etc. That's enterprise computing for you in a nutshell.

    >If you are being forced to use J2EE against your will, ask questions instead
    >of complaining.

    Let me make one thing clear here: I'm not forced by my boss or some other authoritarian instance to use J2EE. I'm forced to use it because there is simply no alternative solution on the market today.

    As for asking questions, it won't cut it, because I already know the answers. It's just that I don't like the answers. That's why I'm complaining.

    I want to see J2EE being radically revamped, so that we can get over this fascination with the underlying low level infrastructure, and focus on the business issues at hand.

    Alex
  35. Is it Java or Object Oriented Programming[ Go to top ]

    Alex,

         The examples you gave regarding the difficulty of using J2EE are true, J2EE can be difficult to use in such a situation as would any programming language; However, I would be interested on hearing what your ideal solution to this is.
         The reason that Java can make issues such as enterprise integration very complex is because it is an Object-Oriented language. The only other solution to the issues you raise is to implement more hard-coding techniques throughout the codebase. The less interfaces and abstractions of implementation that there are, the higher amount of control and ease-of-use there is. And vice versa.
         Not to be antagonistic, but what do you feel is the solution here?

    Thanks,

    Ted
  36. Is it Java or Object Oriented Programming[ Go to top ]

    The less interfaces and abstractions of implementation that there are, the

    >higher amount of control and ease-of-use there is. And vice versa.

    Ted,

    I'm not sure I understand what you meant here. To my mind, the very opposite is true. Lots of hard coding implies, to me, tightly coupled systems which are inflexible and high maintenance. Any subsequent changes usually require visiting many seemingly unrelated places, doing lots of touch ups and so on, with accompanying risk of forgetting to update some crucial pieces.

    A highly abstract system results in a decoupled state, which lowers the cost of maintenance. Could you please describe in more details your understanding of the problem?

    >I would be interested on hearing what your ideal solution to this is.

    An ideal solution would be for the vendors who are supplying this platform to recognize what their true intentions are. When shipping a computing platform (in this case, a platform that serves application logic), there are two possible targets:

    1. serving the underlying machinery (obeying the demands of the underlying hardware/software combo)

    2. serving the end user (obeying the demands imposed by the end user)

    In the present case, the vendors have obviously decided to turn their attention to how to serve the underlying machinery to the best of their abilities. That leaves us, the developers (i.e. end users) out in the cold.

    To me, the ideal solution would be to force the vendors to realign their sights and to invest majority of their efforts in serving OUR needs, not the needs of the underlying machinery.

    If we step back for a moment and try and grasp the reasons why we're using J2EE platform in the first place, we'll see that it's basically in order to deliver business solutions. If I am to develop a business solution using this platform, I'd like that platform to be supportive of my goals. As I've described in another post, if my goal is to send an email, the system (meaning the underlying platform) should do the best it can to support that goal, in a way that makes it extremely easy for me to do so. The system should be made to work hard to eliminate all the noise and fuss from an act of sending an email. Because, when I want to send an email, the last thing I want to think about is HOW is the underlying system actually doing it under the covers.

    If I want to persist the state of a given object, the system should be made to bend over backwards to support that goal, without asking me to make a career out of understanding how is the persistence being accomplished. All I want to see is me sending the message 'make this thing persistent', and the system complying. I don't want to know HOW is that persistence accomplished. Somehow, it will be accomplished, I'm sure, but I need not ever be bothered with the details.

    That's what I mean by 'supporting end user goals'. We, the developers, are the primary customer of products such as J2EE, and it must serve our needs before serving anyone else's needs. I feel, however, that the way the product is designed today, it behaves as if it couldn't care less about my needs. It expects me to become an expert in many trival things that shouldn't even appear on the radar. And that's where they did a lousy job.

    The true prupose of platforms like J2EE is to provide an illusion of a homogenous view of the heterogeneous environment. I know that under the hood things are extremely complicated (that's why they're so powerfull), but I just don't want to ever see it (same as I don't want to see the internals of my microwave oven). I want to deal only with smooth, easy to understand surfaces. That will free my mind to focus on more important things.

    Alex
  37. I don’t understand this argument that J2EE is unnecessarily complicated and most probably never will, even though I heard it lot of times in TSS too. Complexity lies in domain not J2EE.
    J2EE is an API designed to finish the enterprise level task easily, if you don’t want it, Java Standard API doesn’t stop you to do what ever you can do with other MS technology. When you compare EJB with COM+, they both are the same animal and require the same skill level; but some how MS is smarter in the sense they always twist the fact and use complexity against Java and J2EE. On the other hand they always compare C# simplicity with Java, even though the fact is that C# is magnitude of time more complex than Java. BTW just for the comparison purposes, how many of you have seen the framework for the ASP.NET. It is overwhelmingly complex, might be much more complex than any other J2EE API you Java gurus are using out there. I am not criticizing here MS for making it complex, as a matter of fact I really appreciate them, to make our task much easier in terms of eliminating cryptic coding between tags at presentation layer (Java has to catch there, hopefully JSF is as good as WebForms). But again MS was first to hit at presentation layer, and that is their forte, they know that they can catch at the middleware and backend later, where J2EE in my personal opinion is still much more mature than .Net.
  38. I don’t understand this argument that J2EE is unnecessarily complicated and

    >most probably never will, even though I heard it lot of times in TSS too.
    >Complexity lies in domain not J2EE.

    How about this: try to compare J2EE (a corporate-wide application platform) with a typical RDBMS (say, Oracle, which is a corporate-wide database platform). Both J2EE and Oracle can accommodate wide variety of domains. However, Oracle is extremely easy to use compared with J2EE. All one needs to know in order to use phenomenally sophisticated capabilities of Oracle is how to write standard SQL statements.

    We need the same thing on J2EE. We need a simple high level set of concepts that will allow us to utilize all the fantastic capabilities burried inside this hideous machinery.

    Compared to Oracle, everything is way too low level in the J2EE world. Sure, you can also go low level when using Oracle if you wish, but the question is -- why? Why would you wish to work directly with Oracle's flat file system when you can accomplish the same thing using much more succinct SQL statements?

    Alex
  39. Alex,
         I think you over-state the ease of using Oracle somewhat.

    While I can do a great deal with Oracle, in order to leverage its full power I need to understand a lot of concepts, such as:

    How indexes are used by the system. For instance, if I define a temporary table in a stored procedure, and put an index on it, will that index be used? (This is a trick question, I know the answer used to be NO, for Sybase. :))

    How to use nested tables properly.

    How to register and use output parameters properly.

    How to define a table structure that doesn't bring things to a screeching halt under load.

    Oracle doesn't solve those problems for me. I don't get a message "Warning: This table structure may be inefficient." or similar. I have to know.

    Oh, and there is no real SQL standard for defining tables etc. so that tends to be server specific too.

    I do agree with you, that J2EE doesn't really achieve the goals it is supposed to. I always think of J2EE as having "masked and moved the complexity of the underlying issues of transactions, remoting etc. But _not_ solving them." You still need to be very technically wise to build a good J2EE system. I guess your point is you shouldn't need to be if you just spend $X thousand on the platform.

    Basically, I agree with you, but I think your analogy was flawed. Your cell phone analogy was better. :)

    Chz

    Tony
  40. I think you over-state the ease of using Oracle somewhat.

    >
    >While I can do a great deal with Oracle, in order to leverage its full power >need to understand a lot of concepts, such as:

    Tony,

    Again, the true question is: how often would you need to leverage the full power of Oracle? In my previous reply, I've outlined the difference between the things that are PROBABLE vs things that are POSSIBLE.

    Yeah, I know, it is possible to do lots of fantastic stuff in Oracle, but how often are we using those far fetched features?

    For 98% of the time, I find using my Oracle database for the vanilla SQL statements. So, 98% of the time the product beautifully supports my goals. And I think, because of that, it's probably one of the most successfull software products I've ever seen.

    For the remaining 2% of the cases, yeah, we must jump through the hoops, but so what? It's only 2% of the cases, which have amply been offset by the phenomenal support for the bulk of the typical user's needs.

    In contrast, J2EE is not designed to support the bulk of my typical needs. It's left lying bust open, allowing me to gaze at its ugly guts. I find that sight repulsive, and the product to be largely a failure.

    What they need to do is take Oracle (or DB2, or any other commercial RDBMS for that matter) as something to look up to as a shiny example, and build a product that would offer similar level of encapsulation. Because, when you think about it, there shouldn't be much difference between the two -- Oracle is a product that serves corporate data, J2EE is the product that serves corporate business logic. Basically, they are the same beast, it's just that one is a highly polished professional product, the other is a lame ugly amateurish attempt at a product.

    Alex
  41. Alex,

    Honestly, I disagree regarding Oracle.

    To use Oracle I can remain ignorant. Granted (assuming I don't have to create the tables.) To use it _well_, in large scale environments (which is not just probable, it's actual) I need to know how to write efficient queries. I have yet to work on a large scale project where we didn't have to tune the database and know about the database to do it. Maybe we just work on different types of project. I'm typically dealing with millions of rows (as are most people in my industry.) I agree with you, if we're talking about databases with thousands, or tens of thousands, maybe even hundreds of thousands of rows. But when you make it _big_, you need to know more (and in those situations it's OK to need to know more.)

    I agree with you about J2EE (at least for the most part) but I really think Oracle, or any other database, is not the best example. You can see I agree with you, if you read my other posts.

    Oh, and regarding using JNDI to get your mail session. Even if that did hide me, the user, from session admin details, it's a _hell of a lot_ of plumbing to need just to solve that problem. Sledgehammer anyone? There's a nut I need to crack. :)

    Chz

    Tony
  42. To use it _well_, in large scale environments (which is not just probable,

    >it's actual) I need to know how to write efficient queries. I have yet to work
    >on a large scale project where we didn't have to tune the database and know
    >about the database to do it.

    You make an interesting point, Tony. In such cases, if you discover that you must intimately understand how the product works in order to make it do the run-of-the-mill stuff, a reasonable question should be: are you sure you're using the right product for the job?

    Maybe Oracle is not the best tool when it comes to managing such horrendously large amounts of information. Have you looked into the alternatives?

    The whole idea about an RDBMS product is to spare you the legwork you've described here. The only reason you're using it is to save you the time needed to devise those efficient queries. The reason d'etre of Oracle is to produce the efficient queries behind the scenes, using the suggestions you've supplied to it in the form of an SQL statement (an SQL statement encapsulates your *intentions*; the RDBMS must decide *how* to implement those intentions).

    If the RDBMS cannot optimize the implementation of your SQL statements, the conclusion is that it's a lousy product. I was using Oracle for mid sized projects, and I never had the need to go under the cover. With your situation, you could be forced to look at a better product down the road (have you tried DB2, bu the way?)

    If no RDBMS can offer you such service, maybe it's time to look for the solution in other arenas. Maybe OO databases, or an XML-based persistence may be able to provide a better solution to you.

    Please let me know if you make any breakthroughs.

    Alex
  43. It seems like Java is more open so there are more vendors and open source tools provided. .NET is monolithic, owned by one vendor, and doesn't give choice. For instance, for persistence, you WILL use ADO.NET whereas there are probably dozens of O-R mapping tools, entity beans, raw sql, etc. that Java users can choose between for their persistence needs. Same goes for display frameworks, there's ONE model for dot-net versus Struts, Webwork, etc. etc. etc.

    Java provides more choice and is more open and it seems like that's not a bad thing. OTOH you must admit that the simplicity of Microsoft's approach is probably a plus for cost-cutting PHB types who don't want coders spending too much time framework-choosing. That's what I think BEA's tools strategy is trying to equal on the Java side.
  44. "For instance, for persistence, you WILL use ADO.NET whereas there are probably dozens of O-R mapping tools, entity beans, raw sql, etc. that Java users can choose between for their persistence needs. Same goes for display frameworks, there's ONE model for dot-net versus Struts, Webwork, etc. etc. etc. "

    What you say is just not true. You can interact with persistent stores (RDBMSs to be more exact) in many ways with .NET. There's lots of 3rd party libraries available in code-from, DLL form, COM form, etc. ADO.NET lets you treat data stores in a uniform way; much as JDBC does.

    As for display frameworks you can write your own if you want; that's for fat clients or browser clients. There's nothing preventing you from doing whatever the heck you want.
    The only difference is that the frameworks come with the tool and not as a 3rd party add-on.
  45. Fine, there's nothing stopping you from building tools on top of .Net but you must admit there's a lot less independent vendors and open source projects doing value-added frameworks and tools on top of .Net versus Java, specifically because if you do anything that becomes successful, a rip-off is going to likely get folded into the next release from Microsoft. The point is there is way more diversity in the Java universe than the .Net universe...surely you aren't disputing that?
  46. "The point is there is way more diversity in the Java universe than the .Net universe...surely you aren't disputing that? "

    Define diversity.
  47. More companies trying to solve each problem, therefore creating more choice in the marketplace for buyers looking to buy something in any given segment. Its kind of like the difference between a free market and a planned economy. Are you disputing that Microsoft has a lock on the Microsoft tool market? (note that it's the MICROSOFT tool market, whereas the java market isn't called the Sun marketplace)
  48. "Are you disputing that Microsoft has a lock on the Microsoft tool market? (note that it's the MICROSOFT tool market, whereas the java market isn't called the Sun marketplace) "

    I don't think I've disputed anything at this point. I'm still trying to understand your argument.
    As far as the "MICROSOFT tool market" if you mean the market of tools for developing applications to run on MS operating systems then I do dispute that MS has a lock. Java tools, Borland tools, Intel tools, there are tons of tools to do that. I grant you that there aren't many free ones. But they do exist; Java, GNU, etc.

    Am I missing your point?
  49. .NET is Pepsi and Java is Coke[ Go to top ]

    "Basically, I think .NET is Pepsi and Java is Coke" by Jason Hunter

    Cya, going to buy a Coke.
  50. .NET is Pepsi and Java is Coke[ Go to top ]

    Pepsi is currently advertising more:

    http://www.zdnet.com/pcweek/

    Amazing, isn't it? Start with ".NET vs. J2EE: A reasonably level comparison" in the "On Your Radar" section. Note that ZDNET is kind enough to provide access to a TMC white paper (is it PetStore I?) Now check out the "IT Radar" section. Self-explanatory. Immediately below, the "Internet & Web" section. First item: ".NET". What, no Java? Don't worry, you can find something about Java if you look hard enough. Think of it as a Where's Waldo game. Hint: There's a link for Java under "IT Classes".

    So while some people may gloat about Java being a de facto standard or whatever, just remember that Microsoft's marketing dollars aren't sitting around playing with themselves. Microsoft wants .NET to be taken seriously, and they'll buy its entry to the contest if necessary.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  51. .NET is Pepsi and Java is Coke[ Go to top ]

    So while some people may gloat about Java being a de facto standard or whatever, just remember that Microsoft's marketing dollars aren't sitting around playing with themselves. Microsoft wants .NET to be taken seriously, and they'll buy its entry to the contest if necessary.


    True, but then they have been marketing SQL server as a serious database for years, while practically giving it away for free. How come serious companies still pays for Oracle or DB2? Personally I have great hope in Java standing up to .NET, simply because most buyers know that the price of purchase for a software and hardware platform is negilable compared to the cost of having your core-business system break down at a peak hour.

    Maybe I am just to optimistic...
  52. .NET is Pepsi and Java is Coke[ Go to top ]

    You can see the Microsoft machine in the book stores as well. .NET books overwhelm all that is Java. There are not that many .NET titles but there are zillion copies of them. It is obvious that nobody will ever buy more than 10% of them all but the whole idea is to fill as many shelf-metres as possible to make it an obvious choice. You have to look for Java books in the furthest corner and you are lucky to find something good there. -just something I keep noticing time after time.
  53. -
    Usually you can not be 100% sure of anything.

    I just want to ask you,

    Don't you not ever ever feel, deep deep down inside you any tiny whiny little doubt that maybe .NET is better than Java.. I just mean 0.001 of a percent?

    Just curious.

    Regards
    Rolf Tollerud
  54. Mark noisy[ Go to top ]

    "Mark noisy" is not working. It is giving an OracleJSP error.
  55. Mark noisy[ Go to top ]

    And whom might you be trying to mark as noisy?

    Just wait until it works. ;-)
  56. just so[ Go to top ]

    Yes, the time for me and similar guys seems to be up!

    Then the forum will be like a concert with "contemporary electronic art music", with an attendee of nearest friends and the mourning family..

    Regards
    Rolf Tollerud
  57. A change in behaviour perhaps[ Go to top ]

    Yes, the time for me and similar guys seems to be up!


    That's not true. You just have to stop trolling.
    Face this "moderation thingy" not as a problem, but as an opportunity.

    Best regards,
    Luis Neves
  58. just so[ Go to top ]

    Yes, the time for me and similar guys seems to be up!

    >
    > Then the forum will be like a concert with "contemporary electronic art music", with an attendee of nearest friends and the mourning family..
    >
    > Regards
    > Rolf Tollerud

    No way, I will NEVER mark you as noicy, on the contrary, you are the most entertaining part of the serverside "experience"...
  59. Rolf, finns det ngt motsvarande forum för .nöt? Jag vill nämligen bli för det forumet vad du är för det här!

  60. > Don't you not ever ever feel, deep deep down inside you any tiny whiny little doubt that maybe .NET is better than Java.. I just mean 0.001 of a percent?
    >

    Rolf, don't you ever ever feel, deep deep down inside you any tiny whiny little bit that maybe it would be nice to sleep with girls instead? I mean, sure, you have all the rights to be gay if you want to (choice IS a good thing), but please realize that not everyone likes to cross dress. Are you not straight at all? I just mean 0.001 of a percent?

    Just curious.
  61. .NET should "japanize" J2EE[ Go to top ]

    Sorry Rolf but I must say J2EE is better than .NET and Java is better than C# until now. If you have to work with other OS and platforms you don't have any other choices -> Java JVM better than .NET VM.

    One example: some friends of mine in Mexico City can run OpenUSS (EJOSA based - Enterprise Java Open Source Architecture - all Open Source components: Servlet, EJB, etc.) in a Sun server box with SuSe Linux (not with Sun Solaris) operating system + Blackdown JDK successfully. At the moment this can only happen in the Java world. I myself has also successfully deployed OpenUSS at Windows2000 Server. So, you have the CHOICE with Java.

    I've seen a demo about .NET under Linux (MONO project) a month ago. It could not impress me at all. All the stuffs I saw from MONO was already available in Java for a long long time ago...

    A good tip for Microsoft to make .NET better than Java (if you are working for Microsoft, I think you should take this seriously):
    "Japanize Java" - The word japanize is a good choice here (I took this word from Robin Miller's talk in Mexico City):
    - Make .NET technological better than J2EE also for C#. I think Microsoft is capable to do this. There are a lot of good people working for Microsoft.
    - Make .NET cheaper than J2EE. This means, Microsoft has to change their "live-style". All the technological parts of .NET must be cheaper than Java. How can they reach this? Simple: open sourced all the Microsoft infrastructure technologies -> Windows .NET OS because this is the base of all .NET technologies. This will surely boost the .NET over J2EE or Java.

    This is just an easy comparison how Japan's car industries (Toyota, Nissan, etc.) have outperformed almost other car industry's countries in '80:
    - Cheaper.
    - Copy and make it better.

    Both aspects are important for any technologies and products to become successful...

    Let me ask you 2 questions:
    - Would Java/J2EE be very successful like today if you had to pay 1000 US$ for each JVM you have to use or deliver? Nope, I don't think so (Cheap).
    - Would Java be successful like today if Java language were just like Assembler language couple years ago or Java applications can only run in Linux? Nope, I don't think so (Better than other).

    Just my opinion ;-)

    Lofi Dewanto
    OpenUSS http://openuss.sourceforge.net
    EJOSA - Enterprise Java Open Source Architecture
  62. .NET is Pepsi and Java is Coke[ Go to top ]

    "...but the whole idea is to fill as many shelf-metres as possible to make it an obvious choice..."

    The most annoying about .Net books is actually that all the same code samples come in at least VB and C#. If they would restrict themselves to print samples just in one language, the shelf-metres would be much less. As this does not provide any value to what is already there (besides more bucks for the authors) and it is annoying to skim through, I would really appreciate future authors save some of those trees.
  63. Re: .NET is Pepsi and Java is Coke[ Go to top ]

    The most annoying about .Net books is actually that all the same code samples come in at least VB and C#. If they would restrict themselves to print samples just in one language, the shelf-metres would be much less.


    It's not the books that are to blame - it's the framework! (.not: MULTIPLE languages, SINGLE platform)

    I've always thought this is one of .not's drawbacks. With Java you (as a developer) only risk to bump into code written in ONE language. With .not, you may find yourself responsible to fix an application written several languages - at once!
  64. Java is Coke and .Net is "New Coke"[ Go to top ]

    We all know what happened to "New Coke" ;)

    As hard as I try not to partake in .Net bashing I couldn't resist making the comment.
  65. Just a small error about Mono[ Go to top ]

    "Even though there are projects to do .NET on other platforms, they don't have [Web] forms ... so you have to deploy on Windows."
    Actually, there have been web forms in Mono for quite a long time. It's WinForms that are not yet implemented because they are too tied up to Windows. But they have developed interesting alternative GTK libraries that happen to work on Windows too. So there are desktop applications written in C# and that run on Windows (including CE), Linux, FreeBSD, MacOSX.
    But sure, if you're aiming at cross-platform desktop development today, choose Java.
    (and yes, ok, I like Pepsi better, but that doesn't mean I despise Coke drinkers ;)
  66. For more info about Mono WinForms[ Go to top ]

    http://www.go-mono.com/winforms.html
  67. J2EE is way too complcated. Why make kludgy EJB remote calls, doing table scans instead of using table indexes and creating the bulky collections on the EJB side, send them through networks, then iterating them through on the web tier, (not mentioning the over complicated PetStore web tier design). What J2EE should have is JSP, Servlet, Taglibrary, and JDBC, and JMS. Only when situation warrants we would use stateless Session Bean and Message Driven Bean. Otherwise if the J2EE continues to add fancy stuff disregarding the real world applicatons it will just follow the front end SWING suite, good for design pattern studies but hard to use in real world applications.
    Aturo
  68. Charles,

    J2EE is about as complicated as you make it. Sure, EJB is a somewhat advanced topic. If learned well, it can be used well.

    However, I/we at NACSE stopped using EJB's almost a year ago. The good thing here is we have lot's of choices. We decided to begin using ORM tools instead of EJB (although I guess is an ORM tool too...).

    Use what you want. More importantly, use what's right for your company and the job. If you feel that EJB's are too complicated, then maybe they are...for your project, your infrastructure, or your team's skill set (that is not meant as an insult, just that if you don't have certain skill sets, they either need to be developed or not used). For other people/teams/companies, they're the right choice for hosts of reasons.

    Too many people lose perspective on what they do or should be doing. The job is (probably) to develop and protect the information architecture at your company.
    Because of that, you choose tools when and where they are needed. The tool choices and problem set often define the complexity for you. Building a complete Supply Chain Management and integration system in ANY language can be quite complex. Sure, simplest possible solution is usually best. But sometimes your trying to solve complex problems, and that takes pretty advanced tools and developer skillsets. Cold Fusion is great for some things, and so is J2EE.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  69. Microsoft has persistently and agressively claimed that there's little demand for Java applications. The claim has always been perceived as a disinformation campaign, however it raises a curious question. Is there demand for Java applications inside Microsoft? Wouldn't it be completely embarassing for Microsoft to discover that there is a Java application that they are completely dependent on? If this were so, would this not break the Microsft vs Sun case wide open?

    Freshwater Software a Mercury Interactive subsidiary, develops an application called SiteScope. SiteScope is a tool used to monitor the availability of mission critical, distributed systems such as network services, operating systems, Web systems and applications. The tool is widely popular and is used in over several thousand installations. SiteScope is a java application, more specifically it's a web based application that has over 60 different kinds of monitors. If you browse at the list of monitors in SiteScope, its easy to realize how difficult it would be to build such a system in any language. Fortunately, one of strengths of Java is the availability of libraries to connect to almost any kind of system. SiteScope leverages this strength to the hilt.

    It turns out that Microsoft's MSN uses SiteScope to monitor over 1,500 devices. In fact Microsoft may be SiteScope's number one customer, here's the link to Freshwater's customers, notice that Microsoft is at the top of the list. A Microsoft director says:

    "SiteScope gives us the flexibility we need to customize and implement monitoring functions that help us keep our Web services up and running smoothly."

    There you have it folks, ample proof. There's demand for Java even inside Microsoft! Even more surprising Microsoft uses Java to manage their applications. Management products have to be more robust and stable than the applications they manage. In otherwords, Microsoft has implicitly admitted that Java is robust and stable enough to entrust the management of their enterprise.

    Check the news at http://www.freeroller.net/page/ceperez?catname=101+List

    http://www.freshwater.com/PartialCustomerList.htm

    http://www.freshwater.com/SiteScope.htm
  70. Interesting even Mircosoft is using Java. :).

    Microsft's long time partner Siebel has ditched .Not and are using Java.
  71. Explanation[ Go to top ]

    Hi,

       Wrt this quote from the article:

    In addition, Hunter said, the Windows lock-in is understated. "If you're doing .NET, you're still deploying on Windows. Even though there are projects to do .NET on other platforms, they don't have [Web] forms ... so you have to deploy on Windows."

       Could somebody please explain what Jason Hunter meant by this? I took it to mean that if somebody were to deploy a .NET app on a non-Windows platform(how?), they would be stuck because there are no Web forms that can be deployed to access the app. Couldn't we access the .NET app through different means other than Web forms? Not sure I follow this...

    Thank-you,

    Ted
  72. Explanation[ Go to top ]

    Hi Ted,

    Even if Jason Hunter is one of the persons I respect most in this world I doubt very much that he was quoted correctly because what he was supposed to have said makes no sense.

    Mono will have full ASP.NET functionality with User Controls, Custom Controls and "Codebehind" - the same technique that Sun is trying to copy with JSF - the only framework I know of that allows the page to be completely free of code, not even the tags that Velocity puts on the page.

    And when I am speaking of it - don't confuse the "Codebehind" with servlets. ASP.NET have their own counterpart to Servlets - mediator or controlling classes (=Servlet pipeline) that is something completely different.

    Regards
    Rolf Tollerud
  73. Explanation[ Go to top ]

    Free of Code?

    Apple WebObjects
    Tapestry

    And they do work better than ASP.Net where you can have just one page-directive for code-behind.
  74. Explanation[ Go to top ]

    "And when I am speaking of it - don't confuse the "Codebehind" with servlets. ASP.NET have their own counterpart to Servlets - mediator or controlling classes (=Servlet pipeline) that is something completely different. "

    Rolf, I didn't quite understand what you mean with this? Do you refer to Response.Redirect or do you mean .Nets underlying request-response loop with the various events being fired for Application/Session/Page?

    Whereas I think Codebehind is a good (but not new) concept for complete separation of markup and code, it would be still very useful, if there'd be some sort of servlet, which would process/delegate each request before the aspx gets invoked. My findings with ASP.Net were, that you always post directly to a page. I find it very useful to do some common things on each request before handing it off to a specific page/component.

    I'm not familiar with a "servlet-like" technique in .Net that would do that. So, if you could elaborate on the servlet equivalent in .Net you mentioned, I'd like to hear about it. Thanks!
  75. sample[ Go to top ]

    Bob,

    Certainly. Here is "hello world".

    using System.Web;
    namespace net.ariette.macs {

        public class hello: IHttpHandler {
        
            public void ProcessRequest(HttpContext context) {

            context.Response.Write("Hello World!");
            }

            public bool IsReusable {
                get {
                    return true;
                }
            }
        }
    }

    You decide in your web.config file what type of requests that should be handled by "Servlets".

    A slightly more complicated sample:

    using System;
    using System.Web;
    using System.IO;

    namespace net.ariette.macs {

      public class mediator : IHttpHandler {
        
         public void ProcessRequest(HttpContext context) {

            String p = (String)context.Request.Params["p"];
            HttpServerUtility server = context.Server;
            StringWriter writer = new StringWriter();

            switch(p)
    {
                case "login":
                    server.Execute("login.aspx", writer);
                    context.Response.Write(writer.ToString());
                    break;
                case "main":
                    //other stuff
                    break;
                case "basket":
                    Order o = new (Order);
                    o.process(context);
                    break;
            }
         }

         public bool IsReusable {
            get {
               return true;
            }
         }
      }
    }

    After the server.Execute you are still in control; you can also use server.Transfer.

    Regards
    Rolf Tollerud
  76. sample[ Go to top ]

    Thanks, I'm gonna try that!
  77. .NET servlets[ Go to top ]

    It is really fun to use - you can copy right away all the popular Java architectures!
  78. meeting of similar philosophies[ Go to top ]

    Jamie,

    Siebel is not a "long time partner of MS", their acquaintance is a rather short one - and now have MS released their own CRM system.

    I have a suggestion!

    Why don't you follow very closely the attempt by Siebel to put their over-complicated and kludgy enterprise CRM system on top of Websphere!

    That will be great fun!

    Regards
    Rolf Tollerud
  79. Prediction[ Go to top ]

    Microsoft will buy Siebel in 2004. Siebel will never come close to a java port. And even if they could, their architecture would fail. Java cannot support such complexity with any kind of reliability or performance.
  80. On the other hand, Sun for quite a while (to their great embarassment when they found out) hosted their entire Java developer community on Windows/IIS/MS SQL Server/ASP.

    They'd given the company building it for them a free hand and the supplier had chosen the tech they were most at home with.
  81. J2EE the defacto standard?[ Go to top ]

    I've been programming Java for more than six years now, I've done many projects, applets, thin client, thick client, websites, etc. And I just don't like Java. I prefer .NET and generally speaking the development philosophy of MS tools, becuase they make things easier for developers and don't restrain you. You want to make a simple thing? You have a simple solution. You need to have a more complicated architecture? You can do it too.

    Java is not really complex, but it is different from other languages (especially J2EE and the whole web approach) and very very misleading and complicated. There is a difference to me between complex and complicated; complex means an inherently difficult thing to understand, no matter what, it's difficult, like multi-dimensional analysis in maths. Complicated means that you take something easy and you turn it into a difficult thing. That's what Java does, everything is blurry; there are APIs implemented by vendors, but these APIs lack some features (intentionnally, to make it possible for people to implement them quickly, like the XML standard API which is far inferior to Microsoft's one), but vendors make these features available in their implementations. But if you use them, you're not "Write once Run everywhere" anymore. It's usual for vendors to make their APIs slightly specific, to keep you from using other technologies. So what's the use of the standard API, if you have to to do things yourself that should be part of the library? What's the use if you end up using vendor specific functions? That's an example of Java's problems. Try to use ACS (an open source framework for CMS now owned by RedHat) on WebSphere. It doesn't work because each one wants its own implementation of the crypto API. WebSphere has the J2EE label...

    Moreover, Microsoft has made the smart choice to use XML as a standard for data representation along with XML schema, especially in ADO.NET (hell, we made the same choice about three years ago with XML and we're using XML schema for more than one year), while Java architects and programmers are still wondering how they should extract and persist data. This way, they are ahead in web services development (just try it to know how easy it is to make a web service with .NET) and don't lose time. Look at JSF: Java went all the way around to come back to XSLT, but Java's not using standards. The good idea has been there for more than three years.

    The key for Microsoft is time to market and development costs, and they are the best at it, and they're right, because the only thing that matters in the end is to provide good software for a small price and the quickest possible. I hope Java will evolve in a good way, because some clients will impose it to me, and I'm fed up with losing time.
  82. hype and complexity/CORBA[ Go to top ]

    I think the reason that Java doesn't get the hype it used to is because it is now mainstream. It's a good thing for Java because it means it's proven and been accepted by the IT world.

    As far as EJBs being "complex": I agree with some of the other postings - I don't get it. From my experience, I would say that using EJBs to develop distributed, heterogeneous objects is much easier than using CORBA to do so.

    Especially when using code-generation tools (i.e. Xdoclet). Is there some other technology that makes more sense to use? Please let me know.

    -Scott
  83. hype and complexity/CORBA[ Go to top ]

    Scott -

    I too come from a CORBA world - using EJBs (along with many other parts of J2EE) to get my job done is much easier and far more efficient than what I used to do with CORBA.

    I think one expectation of J2EE is that it should make everything easier. For my job it does, but for other jobs it adds a level of complexity to what should be, perhaps, simpler tasks. I think as J2EE evolves, the participants will hopefully address at least some of those issues, though in many cases I would have a certain level of that scope handed off to the tool vendors and I think we are starting to see things go in that direction.


    Cheers
    Ray
  84. hype and complexity/CORBA[ Go to top ]

    As far as EJBs being "complex": I agree with some of the other postings - I

    >don't get it. From my experience, I would say that using EJBs to develop
    >distributed, heterogeneous objects is much easier than using CORBA to do so.

    And using CORBA to develop distributed, heterogeneous objects is much easier than using C++ to do so. And using C++ is much easier than using assembler, right?

    The thing is, one can always come up with an example that illustrates how something is good because there are things that are even worse than that. Like, CORBA is indeed even worse than J2EE, but that doesn't automatically mean that J2EE is good.

    Alex