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

Reni Jansen wrote:
| I must compliment you for your staunch support of whoever made the error
| to arbitrarily deviate from an established convention.

You do know that "support" and "explain" mean different things? Also, that "arbitrarily" means "without reason"? I think it quite likely that Apple *had* a reason. Whether you approve of it is another matter entirely.


| You can say that it is wrong ... but it could have been right when this
| software was made.

Time passes, and what was right becomes wrong. That it may have been right once doesn't guarantee that it remains right forever. It is the burden of the software developer to keep up with such things.


| The error is not trying to locate tools.jar in the filesystem

The error *is* trying to locate a jar file that isn't guaranteed to be there. Lomboz would *work* if it had merely tried to load the class without searching for the jar file. If the inclusion of code causes the program to fail when the omission of that code would allow it to work, that seems pretty clearly to be the error.


| You may see the Sun recommendation as the law, but it is invalid given
| these circumstances.

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?


| I have to warn you that this list has shown people prepared ... to blame
| either you for not understanding or the Lombok people for doing
| something wrong that happens to work elsewhere.

And, as you yourself say, "happens to work elsewhere". Not "was guaranteed to work".


Greg Guerin wrote:
| "Happens to work elsewhere" != "Certain to work everywhere".
|
| Speaking French happens to work in many countries (Algeria, Switzerland,
| parts of Canada), but it won't get you very far in many other places
| (e.g. Australia, Guatamala, South Africa). Nor will trying to spend
| Mexican pesos in Texas. Such assumptions are naive, or at least
| uninformed.

Reni Jansen wrote:
| Just because you can think of something that is naive or at least
| uninformed does not mean you are making a valid point, are you?

The discussion of language was an *example* of the claim that

"Happens to work elsewhere" != "Certain to work everywhere".

The naivety was imputed to those who assume that "happens to work" necessarily implies "guaranteed to work". It was an editorial comment *related to* the point, not an argument *supporting* the point.


| No, the error is in assuming every product is adapted to the latest
| release, in this case to the extension mechanism.

Considering how old the extension mechanism is, stating that expecting a program to use the extensions mechanism is "assuming every product is adapted to the latest release" is a rather far-fetched claim. Or is that mechanism actually new to 1.4.2?


| The portability problem is with the platform that requires separate
| installation instructions for some packages. In this case it is Apple's
| VM that requires this and/or newsgroup support.

"Portability" refers to the ability to move a program between *different* platforms. "Different" means "not the same", and implies that there will be things about one platform that *do not work* on another. The *portable* program takes those differences into account. It is the *nonportable* program that requires that all platforms be identical.


Greg Guerin wrote:
| Nor am I defending Apple's decision. ... In some sense, Lomboz is in
| error. Either for assuming something is portable when it isn't, or
| failing to document a non-portable aspect of their product as such.
| Pick one and file a bug-report with the product's maker.

Reni Jansen wrote:
| No, you are defending it by stating that users and software producers
| are wrong.

He is claiming that Apple is within its rights to *make* the decision. Whether he approves *of* the decision is another matter.

Nothing in that paragraph says anything at all about users. No user is responsible for "assuming something is portable when it isn't", nor for "failing to document a non-portable aspect of their product". On the other hand, the software producers are very *much* to blame. They have two choices: modify their software to adapt to a changing world, or leave the software unmodified and insist that the platforms adapt to the software. You seem to argue that the latter is the correct choice.


| And no, I am not filing a bug with the product because a) I
| am not a user of that particular product but was trying to help someone
| else with a problem and b) the product is very probably not in error.

If the product does not follow *current* guidelines, then it is indeed in error. If you choose not to file a bug report, then you presumably feel that you are doing the developer a favor by not telling him his product doesn't work on OS X.


| A company that requires re-install of the system partition for fallback
| of a Java VM certainly has no feel for the deployment logistics of
| enterprise computing.

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.)


| [I like Apple] to have a shot a competing in the enterprise computing market.
| This is not going to succeed while pointing out that the small print tells
| you to "not install on production machines" when the previous release has
| showstoppers.

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!


| 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.)


| Also, when somebody tries package X and it does not install, run, of
| fails otherwise, there is a possibility they would give up on OSX at
| all.

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.


| [Users with failing software] should be told how it can be made to work,

They *are* being told: get the software vendor to remove the platform-specific assumptions that were written into the program. For most users, that's all they *can* do.


| do not criticize users and developers that are not familiar with the
| fine print

I'd dearly love for you to point out where all these critisms of "users" you keep referring to are. As for the developers, it's right and proper to criticize them for not being "familiar with the fine print", because it's their *job* to be familiar with it.


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. The users are going to update their systems; any software that doesn't work will be replaced by software that does. If Lomboz isn't revised to work with the Mac, someone else will write something that does, and Lomboz will begin the slide into obsolesence.

However, I doubt very much that you will be convinced, so there seems little point to continuing the debate.

Glen Fisher
_______________________________________________
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.