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

There is nothing in the JLS or the JVM spec that specifies the
path "jre/lib/tools.jar" or that even requires the existence of
a "tools.jar" file. To assume otherwise *is* an error on the
part of the programmer.

I'm not so much defending Apple here but defending portability,
which has always concerned me even before Java existed. I have
to deal with Other People's Code all the time and fix their
invalid assumptions, whether it's Java or C or Perl or something
else. I code on many platforms and am certainly not an Apple
apologist. I like writing Java on OS X *because* it catches
non-portable assumptions.

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

I don't know where users came into this, users shouldn't care at all.
It is the programmer assuming things that are not correct that causes
portability problems.

This is beginning to sound like a debate I had years ago. It was in
regard to C code and had nothing to do with vendor differences, but
his argument sounded like your current one which, I believe, boils
down to "everybody ELSE does it that way, therefore Apple is wrong".

This particular person insisted that scanning a directory for files
that ended with ".gif" was the correct way to find images, and refusing
user input that didn't end in ".gif" was correct behavior. Well, there
is nothing in the GIF definition that requires a particular file extension
or even that the image data lives in a file. To assume so is an ERROR
on the programmers part. Conventions are != requirements. The correct
way to determine if it is image data is to look for the GIF87 or GIF89a
tag in the file.
But he *insisted* that, because "everybody" uses the .gif extension,
his way right. I think we can all agree that he was wrong, and
likewise I assert that assuming "jre/lib/tools.jar" is incorrect from
a portability standpoint, Apple or no.

IBM had a product (VisualAge?) which stored both source code and
compiled classes in a behind-the-scenes database. This was perfectly
legal under the Java specs, but it would fail the "jre/lib/tools.jar"
test.

Assuming too much is a hinderance to portability. Even if everyone,
including Apple, *did* use jre/lib/tools.jar I would still say that
it is incorrect to assume it, because it is NOT required.

When SuperCoolPlatformXYZ(TM) comes out and breaks that assumption,
I will be the first to support it, because my code will still work.

- Stephen


On Wednesday, March 17, 2004, at 01:17 pm, Reni Jansen wrote:

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.

--
Stephen Paulsen @ Synergex
My post, my opinions.
_______________________________________________
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: 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.