Krishnan Subramanian wrote:
>
> Joe,
>
> First off, you seem to take a great deal of pleasure in explaining
> the past (C++ or Borland's w.r.t Paradox for example) but I fail
> to see the relevance of those topics to the [technical] discussion
> at hand.
I believe I was very specific in pointing out that was an analogy to the
trends that I see in the promotion of the use of entity beans.
I am not quite sure how I could have made it clearer that it was an
analogy of trends.
>
> Second, you've shrugged off a lot of the content of my writeup as
> 'buzzwords' and 'sales brochure material'. But I've yet to notice
> any [technical] arguments to substantiate any of your claims (are
> there any?).
>
You were making two technical points about your product. The first that
was that your product would solve a number of general purpose problems
("complexity", "Longevity", etc.)
I believe I cited indirectly references in several different journals
where none of those matter in the vast majority of software developement
because those although the terms are taken seriously the practice is
not.
If you want to you may refute that those studies even exist - that I
made them up. Or you want to refute it with another study that
contradicts those findings. Feel free to do either.
Your second point is that your product specifically addresses technical
issues specific to the EJB container market. I don't believe that I
claimed that wasn't true. I am sure that your product does do that. I
am questioning the value of those issues in the overall market in the
first place. And I am not claiming that no one will ever find them
useful. Just that in my experience they have not had a discernable
(measurable) impact on the stuff that I have worked upon.
Naturally that is an opinion. Perhaps if you have worked in a large
number of market segements outside of Borland your experience is
different. If so feel free to share that.
> Third, Java is and probably will always be slower than C/C++, but
> surely that is not the issue at hand. Nor is the future of any kind
> of technology or its anticipated acceptance/usage in N years from
> now.
>
The only time I mentioned C++ was in the analogy that I used. And I
didn't mention performance at all in the response I sent you (and I
don't think it is really relevent to the topic in general.)
Apparently my analogy was not clear.
I was trying to show how the advantages of C++ were immediately apparent
to those that used it and with time continued to be useful. This lead
to the rapid acceptance of C++.
Conversely, still as an analogy, object oriented databases did not meet
the initial high expections. Those that used them initially were not
convinced of the benifits and over time the market share reflects this.
It took C++ 10 years or more to really own the market. It only took
java about 4-5 years to reach wide spread appeal (although based on
Software Development Nov 2002 there are more C++ developers.) I would
expect that a new methodology now would take less than 10 years to
overwhelm the market. And j2ee has been been out for at least 3 years
now.
So based on the above analogy I would expect the benifits of the
technology to be much more apparent than they appear to be to me at the
current time.
> I am a technical guy and so are my posts to this forum. So lets
> keep it at that.
>
As I do.
> This interest list is quite specific to EJBs and so was my earlier
> post. Many don't believe in EJBs and it is not my intention to start
> an "To EJB or not to EJB" debate. My posting was quite specific
> and was meant to dispel some of the common misconceptions people
> seem to have regarding entity beans (in a lot of projects using
> EJBs).
>
And my post was intended to point out my experiences and perceptions as
to what I have seen.
> I also fail to see the relevance of a DVD driver using BMP/CMP
> entity beans that you referred to earlier. If you do not see the
> advantages of EJBs, then start an "An EJB or not to EJB" debate.
>
Because many projects are not solvable by using EJBs. Certainly a large
number are not. I would argue that the vast majority are not. And many
of those that are specifically appropriate to the technology are not
significantly (measurably) helped by it.
> Lastly, regarding BMP vs CMP performance number comparison, it is
> based on empirical data. ECperf kits are now being made available
> by several vendors (including us), so feel free to download and
> give BMP vs CMP a whirl. (Btw, to save you some time, I should
> point out that all ECperf submissions till date have been based on
> the CMP version of the benchmark and not BMP. Why do you suppose
> that is the case?)
>
I was trying to point out that you made a specific numerics claim that I
was not able to confirm by doing a search for that data.
If you want to provide a specific link that details the results and the
systems tested then feel free.
> -krish
>
> PS (not to be mistaken for sarcasm): Surely, it wouldn't take
> a week to configure connection pooling for an AppServer. Have
> you tried the technical newsgroups of that vendor? Or examples
> bundled with that AppServer? (Or try Borland Enterprise Server ;)
>
P.S. I don't tend to lag behind new technologies. I don't believe this
list existed three years ago which is when I had that particular
problem. I don't believe there were that many resources and I do
believe I investigated them all. And I am also certain that Borland
didn't have a product then (were you even called Borland then?)
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
