User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040924
email@hidden wrote:
Todd O'Bryan wrote:
| So, it seems that most of what Sun provides is just Java code for
| various added APIs with new releases of software.
|
| ...
|
| Or is there more going on here than I think?
I replied:
| Much more. Many of the library classes call native methods to do the
| heavy lifting; every one of those methods has to be implemented and
| debugged anew for each platform. (For example, the "concurrency"
| classes require the implementation of the machinery which allows
| lock-free access to variables shared across threads.)
Ken wrote:
| I disagree with this assertion,
You disagree with the assertion that "there are many native methods, and they must all be implemented and debugged"?
No. But I disagree with any *implication* that it not practical to
implement. If you re-read your original response from a devil's advocate
perspective (or just anyone who thinks Apples JVM should be
OS-backwards-compatible), its interpretable as an justification for
Apple to not provide 1.5 to earlier platforms. Next time, please dont
delete my response keywords:
".. assertions, if its is meant to imply..."
As that's the only assertion I made, that's the only assertion you *can* be disagreeing with. Explain, then, how Java--any version--can be ported *without* implementing all those native methods.
Thats *exactly* the purpose of the JVM, to implement the abstraction
layer and shied the developer from platform version specifics. I think
we both already agree on this.. And I think we both *probably* agree
that it can be done on, say, 10.3? How about 10.2? If perhaps you say
that it cant be done on these versions, then surely you can explain why,
and what the difference is between Sun, IBM, or Oracles, (etc, etc) JVM
designs, and Apples.
(Well, on rereading, I notice I also stated that the "concurrency" classes require implementation of lock-free variable access. Perhaps that's the assertion you disagree with. If so, then you may want to read the various papers by the designers and implementers, as that's where I got the information from.)
| if it is meant to imply that Apple
| coudnt write a 1.5 version for older mac OSs,
How *do* people keep reading such off-base "implications" into perfectly straightforward explanations?
I suggest you read what I wrote again. Now, look for the place I said "there can't be a 1.5 for 10.3 or earlier." Then, point it out to me, because I like to stay aware of what I say, and apparently I missed that one.
Again, I fully qualified my original statement to say "if it is meant to
imply that it cont be done". Sorry you interpreted in an offensive way,
and I'm sincere about that.
As an extra-credit exercise, explain the logic whereby "there are many native methods, and they must all be implemented and debugged" gets construed to mean "Apple can't implement and debug those methods for 10.3 and earlier."
Answered above.
| the low-level OS abstraction layers can almost ALWAYS be implemented
| even on old platforms, or at least emulated (except for some overly
| complex native window stuff).
Notice: even *you* hedge your claims: "*almost* always". Do you know for a fact that this is *not* one of the exceptions to the general rule? (Since you seem prone to putting words in that aren't actually there: no, I am not claiming it *is* an exception. I don't know whether it is or not.)
My "almost" does in fact apply to the exception of native window
tookits. Thats where it stops, based on my current experience and
knowledge of JVMs.
And what about overly complex networking stuff? Or overly complex synchronization stuff? Or...? To port Java 1.5, you have to port *all* of it, even the "overly complex ... stuff".
Agreed; We know a JVMs's design tries to touch only the most limited set
of hooks into the OS specifics; that limited set of abilities is
probably its largest shortcoming. So your above statement is accurate
but is construable as to mean there's some networking or synch stuff
that only going to be available to Tiger is again interpretable as "its
not do-able". Or, do you agree that since the JVM/binary portion has
been coded to work in Tiger that it cant be made to work on Panther?
Again, implication.
| I truly regard Apples lack of commitment to providing newer JVM
| availability, for their older OSs, as a greedy sales motivator
Bingo! Give this man a prize! You got it the first time!
You have some fine argument skills. Sounds like your the one handing out
the prizes, or maybe even the judge. Wisdom comes with age, usually.
You clearly don't understand what kind of organization Apple is.
Now, hand your self the prize, for bold, and acusational assertions -
you didnt even hedge your bet. Shame.
Apple is a *business*. Apple is *not* a charity. Apple is a *business*, and businesses are run to maximize *profit*. How does Apple make a profit? By *selling* stuff. How does Apple encourage people to buy what they're selling? By using "greedy sales motivators". Businesses that sell stuff *without* using "greedy sales motivators" *fail*. Thus, it is those very "greedy sales motivators" that are keeping Apple in business, turning out the Macintoshes and iPods you know and love.
Yes, that why interoperability and choice made some other software
company into the predominate one, and who yet even another operating
system is gaining market share.Tell us why? So, Harvard Business, was
it? Your VERY certain that youre right, though.
| Making the 1.5(5) jvm only available for Panther is just bad
| for the community,
Again: Apple is not a charity. Apple is not *trying* to improve the community. They are trying to *make money*. If they can improve the community *and* make money, they probably will. But making money takes first priority. If they don't make money, they go bankrupt, and cease to exist.
And to make money you have to convince your customers that they're
making a long term, viable investment.... not soon-to-be obsolete
"stuff". This increases market share, and sales. Im sure you agree on
this one :-) (if not, witness the previous poster who just bought 3K
worth of hardware and found out hell have to spend more money in 6
months)...
| becasue it produces as many compatibility problems
| as, say, using native code would.
Can you offer evidence in support of this claim? (Again, since you're weak on reading what's actually written: I am *not* claiming that that there are *no* compatibility problems. I'm questioning your claim that, by not backporting Java 1.5, Apple is creating *as many* compatibility problems as by making people write in Objective-C instead.)
| Sad.
Yes, not seeing reality for what it is *is* sad.
Glen Fisher
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
