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

Greg,

I must compliment you for your staunch support of whoever made the error to arbitrarily deviate from an established convention. You must have read the other post, on jsse.jar, today, which is not found by jikes.
On 17-mrt-04, at 19:45, Greg Guerin wrote:

But classes.jar is already on the boot-classpath, which is the property
named "sun.boot.class.path".

It's not in the CLASSPATH env-var, nor is it in "java.class.path", but that
hasn't been necessary or even recommended since the first appearance of JDK
1.2:


What would be the point of stating this, when there is software in existence that uses the CLASSPATH environment variable to locate classes? You can say that it is wrong (like I predicted you would) but it could have been right when this software was made. Also, some software could be designed to stay compatible with the older versions of Java. The error is not trying to locate tools.jar in the filesystem (what seems to be your comprehension of the problem), but finding a class that is customarily in tools.jar, and that you could put on the classpath when there were a tools.jar to be found. You may see the Sun recommendation as the law, but it is invalid given these circumstances.

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

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

What's that to do with the price of fish?
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?
Or even making sense, for that matter.

The structure of a J2SE installation is not standardized.


In that sense, anyone who assumes a "jre/lib/tools.jar" is wrong. Or is at
least wrong for every Java product except Sun's current downloadable
products.

No, the error is in assuming every product is adapted to the latest release, in this case to the extension mechanism. The error is also in arbitrarily repackaging, so that the user that follows the installation instructions is left with nothing. 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. I find it very hard headed that there is not even a symbolic filesystem link.

Nor am I defending Apple's decision. I'm simply pointing out that there is
permissible variation, and pretending there isn't is a portability error.

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.

No, you are defending it by stating that users and software producers are wrong. 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.

As commendable you are in defending Apple, you are not helping it. The quality of Apple's JVM has become very good over the last few years, but I still cannot recommend it to any company that would ask my advice on this. One reason is this problem of arbitrary deviation of conventions (at least at the rate of us never being presented the rationale for the difference), the other reason is the all-or-nothing install process that is only tolerable when it is never wrong. 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.

I am taking the time to point this out because I like my Apple machines and Mac OSX as a home development platform and like them 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. 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. 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.

They can also turn to mailing lists, and there is no point in them being told that although it works on Windows, AIX, z/OS and Linux and not on Mac, Apple is right. They should be told how it can be made to work, and the intelligent and hardworking people at Apple Java development could try to see the merits of striving for adhering to the conventions that make for the least of problems.

On this particular PowerBook, I can boot Windows in all versions, VAX/VMS, VM/370, Linux, Linux/390, BSD, DOS, OS/2 and even OS/360 through MVS 3.8J. The only thing that is not flexible about it is the native Java VM install. It is odd that I have to boot into NT to verify some things and then can run any release of any VM I want. I'd rather stay in OSX, but there will have to be some amendments. Please help
Apple to implement those and do not criticize users and developers that are not familiar with the fine print but are trying to get some work done.
_______________________________________________
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>)



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.