Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using Lomboz plugin with Eclipse

You mean that Sun--the vendor and provider of the Java implementation in question--is *not* the final authority? Who would know better than Sun how Java behaves, and what correct practice is?

The reality of its use is the final authority. There are bugs and documentation errors. The paying user is the final authority. Particularly weak about Sun and Java is how in 1997 some API's already were declared legacy. But I bet they would not dare to take those out.


It is the *nonportable* program that requires that all platforms be identical.

The Java VM is designed to behave identically on all platforms when executing bytecode. Still, this is a quotable expression in the tradition of "War is Peace. Freedom is Slavery". It is the deployment that is not yet portable enough. We must solve that by speaking out to Apple when there is something that is easy to solve.


Color me amazed! I never knew that "deployment logistics of enterprise computing" don't include making backups of critical files and systems before installing new software. Apparently, it's also the norm for enterprise computing to impulsively install every new release as soon as it comes out, without putting it through any sort of evaluation first or waiting to see whether anyone else encounters problems. (I'd think that a business that depended on computers for its livelihood would take greater care, but apparently not.)

Enterprise computing is mostly about compulsively backing up everything. It is also about designing *efficient* fallback and fallforward scenarios; some vendors do not cooperate.

Enterprise computing also routinely uses for production work software that is explicitly stated not to be suitable for production work. The things I never knew!

A lot of projects run with beta level software of middleware and vendor applications. It is because functionality is needed and bugs were identified during rigorous testing that the vendor did not yet identify. I worked on a financial workstation that needed weekly builds of a particular OS to keep moving forward. This is not new, you only did not experience it yourslef probably.



| Most of the time, the operational department has to support as many VM versions
| on a machine as there are (sometimes contractual) requirements from the applications.
| This is not possible on Mac, and that is a pity.

Why not? Can't the contracts be renegotiated? And what do you do about versions of the JVM that never existed on the Mac? (There is, for instance, *no* Java 1.4.0 for the Mac. Apple went directly from 1.3.1 to 1.4.1.)


Like I said, that is only bad for Apple, and only when it does want this market. The graphical people appararently first seem to wait years for Quark and then still want to be their customer. I can tell you that this is a different world.


Anyone ill-informed or unthinking enough to conclude that the entire OS is worthless because *one program* has problems is likely to give up on OS X because it's not Windows.

And we would not want those people as customers running on XServes if we were Apple, wouldn't we? Even if that *one program* is their 45 million dollar in-house system?

Overall, your argument boils down to "developers shouldn't have to modify their programs as a result of platform vendor changes". Unfortunately, change is inevitable. The *successful* developers will be those that *do* the modifications; the *unsuccessful* ones will be those that insist that the platform vendors guarantee compatibility with all previous releases.

No, my point is, the *unsuccesful* platforms require lots of care before standard stuff runs. Change is inevitable, but my ca. 1986 MVS code still runs although it runs on a totally different OS. Some of it would have run around 1970 when the platform was not called MVS yet. Some 1968 binaries are known to run. It is about caring for the customer. That was important when computers cost a lot of money.
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Using Lomboz plugin with Eclipse (From: Greg Guerin <email@hidden>)
 >Re: Using Lomboz plugin with Eclipse (From: René Jansen <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.