Mac free compilers

[Andrew Thompson]

| In article <[email protected]>,
|
| >:| >:| In article
| >:<[email protected]>,
| >:
| >: > ....the default JVM used by a packaged app will be 1.3.1
| >:unless the
| >:| > entry described (and I'm assuming it's correct) says to
use
| >:1.4.1 or
| >:| > newer (and 1.4.2 developer previews are available).
| >:|
| >:| You seem to be right. I just ran a test and if a packaged
app
| >:has
| >:| /no/ JVMVersion setting in its Info.plist file, then you'll
get
| >:| Java 1.3.1 even though Java 1.4.1 is on board.
| >:
| >:Where is the logic there? It is idiotic!
| >:1.3.1 apps will work under 1.4.1, whereas
| >:a 1.4 app is not gonna work on 1.3..
| >:
| >:Sounds like echos of the MS/JVM trick,
| >:but the interesting thing is that while that
| >:would work for a company that has a
| >:stranglehold on the market, it certainly
| >:will not for Apple.
| >:
| >:For those that would care to investigate Mac/1.4
| >:comatibility further, I found this page at Sun..
|

:http://java.sun.com/developer/technicalArticles/JavaLP/JavaToMa

c3
| >:/
|
| What you call idiotic makes perfect sense to me.
|
| Since the bulk of OS X users are going to be using 10.2, which
is not
| guaranteed to have anything beyond 1.3.1 installed, defaulting
to that
| JVM simply means less trouble for the deploying developer.

The developer targeting 1.3.1?
The world moves on!

I would guess that more people are
developing for 1.4, and that 'both'
programmers targeting 1.3 should drag
themselves (kicking and screaming) into
the present.

| ...In addition,
| there were some problems (bugs) in 1.3 which were fixed in 1.4,
and I
| found that workarounds for those sometimes cause unusual
behavior if run
| under a 1.4.x JVM. So I don't understand why you consider that
idiotic.

Because the opposite should be the case,
if a developer has used (what sounds from
your description) 'hacks' that require the
1.3 JVM, then it should be _those_ developers
who have to worry about ensuring the 1.3
JVM is used.

Otherwise, use the latest.

| More importantly, however, the presence of both JVMs gives you
the
| ability to specifically target one over the other -- for
whatever reason
| you might have. Is choice bad?

And if I do not specify ('choose') a JVM,
which is the most logical _default_ Steve?

1.3? 1.1? 1.4? None of them!

It should use 'the latest' JVM, _whatever_
JVM version that is (e.g. I would hope that my
projects will have no trouble running unaltered
under 1.5).

Choice is not bad, but confusion is.

| It's really not relevant to compare anything about OS X to any
product
| from M$. OS X has a BSD-style kernel -- as different as night
and day.
| But I fail to see any comparison at all between the M$ trick of
having
| their own JVM vs a Sun JVM. Sun doesn't produce one for Apple.

Fair comment. I still do not think it makes
any sense to _default_ to an older JVM though.

And I am not very keen to try and figure
out how to deal with Apple's info.plist files!

[ ..wanders off ..muttering and grumbling. ]

 

[Steve W. Jackson]

::| In article <[email protected]>,
:|
:| >::| >:| In article
:| >:<[email protected]>,
:| >:
:| >: > ....the default JVM used by a packaged app will be 1.3.1
:| >:unless the
:| >:| > entry described (and I'm assuming it's correct) says to
:use
:| >:1.4.1 or
:| >:| > newer (and 1.4.2 developer previews are available).
:| >:|
:| >:| You seem to be right. I just ran a test and if a packaged
:app
:| >:has
:| >:| /no/ JVMVersion setting in its Info.plist file, then you'll
:get
:| >:| Java 1.3.1 even though Java 1.4.1 is on board.
:| >:
:| >:Where is the logic there? It is idiotic! 1.3.1 apps will work
:| >:under 1.4.1, whereas a 1.4 app is not gonna work on 1.3..
:| >:
:| >:Sounds like echos of the MS/JVM trick, but the interesting thing
:| >:is that while that would work for a company that has a
:| >:stranglehold on the market, it certainly will not for Apple.
:| >:
:| >:For those that would care to investigate Mac/1.4 comatibility
:| >:further, I found this page at Sun..
:|
:>:http://java.sun.com/developer/technicalArticles/JavaLP/JavaToMa
:c3
:| >:/
:|
:| What you call idiotic makes perfect sense to me.
:|
:| Since the bulk of OS X users are going to be using 10.2, which
:is not
:| guaranteed to have anything beyond 1.3.1 installed, defaulting
:to that
:| JVM simply means less trouble for the deploying developer.
:
:The developer targeting 1.3.1? The world moves on!
:
:I would guess that more people are developing for 1.4, and that
:'both' programmers targeting 1.3 should drag themselves (kicking and
:screaming) into the present.

This isn't about the developer -- it's about the user. As much as a
developer might want to, one can't mandate users to move up. (I was
quie surprised recently to see something about how many Mac OS X users
still have 10.1, when 10.2 was such a major improvement, and 10.3 is
better still.) In many cases, I'd simply say "use the latest JVM or
don't use my product" -- but that's not always acceptable, depending on
who's giving the orders, if you know what I mean...

:
:| ...In addition,
:| there were some problems (bugs) in 1.3 which were fixed in 1.4,
:and I
:| found that workarounds for those sometimes cause unusual
:behavior if run
:| under a 1.4.x JVM. So I don't understand why you consider that
:idiotic.
:
:Because the opposite should be the case, if a developer has used
what sounds from your description) 'hacks' that require the 1.3 JVM,
:then it should be _those_ developers who have to worry about ensuring
:the 1.3 JVM is used.

It's not "hacks" that were involved. The specific situation I had in
mind was something I encountered in my own work (which isn't available
on Mac OS X, since my company's only supporting Windows and now Linux).
There was a problem which, if memory serves, related to the ToolBarUI
class. Because of some bugs, and because some methods and members
needed to work around it were private, I had to replace it with my own
class that was a modified copy of Sun's where I implemented the
workaround and then modified it further for my specialized needs.
Unfortunately, when Sun fixed the bugs there in 1.4, my class didn't
behave well in 1.4 (and not because of my workaround). At that point I
went back and properly subclassed Sun's class and then overrode the
methods that I needed to have special behavior -- the way it should've
been done to begin with.

:
:Otherwise, use the latest.
:
:| More importantly, however, the presence of both JVMs gives you
:the
:| ability to specifically target one over the other -- for
:whatever reason
:| you might have. Is choice bad?
:
:And if I do not specify ('choose') a JVM, which is the most logical
:_default_ Steve?
:
:1.3? 1.1? 1.4? None of them!
:
:It should use 'the latest' JVM, _whatever_ JVM version that is (e.g.
:I would hope that my projects will have no trouble running unaltered
:under 1.5).
:
:Choice is not bad, but confusion is.

I'm not in disagreement with you on this point -- not at all. All
things being equal, I'd always prefer to use the latest available JVM --
especially if I need not expect any anomalous behavior from workarounds
as described above. This is what Apple decided to do, and I see some
benefits in it, even if it's not what you and I would've done.
Personally, I think that including both JVMs should've been advantageous
only for developers at first (testing in multiple JVMs and so on), and
then if some savvy user realized that their web browser, for instance,
worked better using the older JVM than the newer one, there would be
some mechanism available for them to have it make the older choice.

:
:| It's really not relevant to compare anything about OS X to any
roduct
:| from M$. OS X has a BSD-style kernel -- as different as night
:and day.
:| But I fail to see any comparison at all between the M$ trick of
:having
:| their own JVM vs a Sun JVM. Sun doesn't produce one for Apple.
:
:Fair comment. I still do not think it makes any sense to _default_
:to an older JVM though.
:
:And I am not very keen to try and figure out how to deal with Apple's
:info.plist files!
:
:[ ..wanders off ..muttering and grumbling. ]

As I said above, I think you've assumed I was defending Apple's
implementation (and my post might well have made it seem so), when I
really agree that the latest should be the default. Personally, I've
never done any development on my Mac in Java, so I've got no clue how to
manually mess with the plist file or use the IDE. If and when my
company decides I can include OS X on the list of supported platforms,
I'll either have to learn how to do that manually or tinker with the IDE
on the Mac and have it help. While I may regret saying this, I look
forward to getting the opportunity to expand our product to the Mac,
despite knowing it's going to put extra layers of confusion in place for
me.

= Steve =

 

[Andrew Thompson]

| In article <[email protected]>,
....
| >:And I am not very keen to try and figure out how to deal with
Apple's
| >:info.plist files!
| >:
| >:[ ..wanders off ..muttering and grumbling. ]

I've reconsidered my prior stand, as soon as I
get packages sorted for the JOLC, I might look
into these info.plist files further.

After all, I can whinge and moan, .._or_ I can
do something constructive, and doing something
constructive often takes less effort!

| As I said above, I think you've assumed I was defending Apple's
| implementation (and my post might well have made it seem so),
when I
| really agree that the latest should be the default.

Thanks for clarifying, I did have that impression..

 

[rbs]

:| You seem to be right. I just ran a test and if a packaged app
:has
:| /no/ JVMVersion setting in its Info.plist file, then you'll get
:| Java 1.3.1 even though Java 1.4.1 is on board.
:
:Where is the logic there? It is idiotic!
:1.3.1 apps will work under 1.4.1, whereas
:a 1.4 app is not gonna work on 1.3..
:
:Sounds like echos of the MS/JVM trick,
:but the interesting thing is that while that
:would work for a company that has a
:stranglehold on the market, it certainly
:will not for Apple.
:
:For those that would care to investigate Mac/1.4
:comatibility further, I found this page at Sun..
:http://java.sun.com/developer/technicalArticles/JavaLP/JavaToMac3
:/

What you call idiotic makes perfect sense to me.

Since the bulk of OS X users are going to be using 10.2, which is not
guaranteed to have anything beyond 1.3.1 installed, defaulting to that
JVM simply means less trouble for the deploying developer. In addition,
there were some problems (bugs) in 1.3 which were fixed in 1.4, and I
found that workarounds for those sometimes cause unusual behavior if run
under a 1.4.x JVM. So I don't understand why you consider that idiotic.[/QUOTE]

Yes, ditto. Makes sense to me.

A Mac-packaged Java app which does not have any JVMVersion
specification in its Info.plist was probably created using a
version of ProjectBuilder which did not know to insert that
field /and/ a version of ProjectBuilder released at a time
when Java 1.4.x was not available on the Mac at all. Only
when Java 1.4.x was available on the Mac did ProjectBuilder
and subsequently XCode start inserting the JVMVersion info into
the Info.plist.

To give an example from my own experience, I have a Java app
which had a bunch of TreeTable drag and drop code. That app
was first released publicly at a time when the JVMVersion
tag was not set in the Info.plist. It's a good thing for me
that OS X opts to use Java 1.3.1 if the JVMVersion info is
missing, because I have found that DnD code is completely
nonfunctional under Java 1.4.1 (and I have not yet had the
time figure out why). People who downloaded my application a
year ago can still use it and I don;t have to explain why it
suddenly stopped working the day they upgraded their copy of
OS X, and got an updated Java while they were at it.

 

[rbs]

BTW: I would like to comment that although the possible
differing versions of Java available on a Mac sounds like a
confusing headache, I have in the past two weeks found
that it has been an almost non-existent worry in publicly
releasing a cross-platform Java app.

A piece of free Java software that I have written has recently
been "in the news", with the result that either the application
has been downloaded or the applet version has been viewed
possibly as much as 100,000 times in two weeks. (I don't have
the server stats at hand, but I'm serious in saying 100K.)

By far the /biggest/ issue of confusion I have run into
in answering e-mail during those two weeks has been from
Windows users who don't understand why the app won't run on
their computers, at all. Invariably the reason has been that
they don't have any JRE installed.

Among the Mac users, the only issue has been that a very few
people have had a version of StuffIt Expander which mangles
execute permissions when uncompressing a download.

 

[Andrew Thompson]

.....
| A piece of free ..

I recongise the case for commercial software,
but I always love hearing that word.

|..Java software that I have written has recently
| been "in the news", with the result that either the application
| has been downloaded or the applet version has been viewed
| possibly as much as 100,000 times in two weeks. (I don't have
| the server stats at hand, but I'm serious in saying 100K.)
|
| By far the /biggest/ issue of confusion I have run into
| in answering e-mail during those two weeks has been from
| Windows users who don't understand why the app won't run on
| their computers, at all. Invariably the reason has been that
| they don't have any JRE installed.

Have a look over the 'alt' and 'no applet' tags,
that at least gives some feedback.
[ check .. http://www.physci.org/codes/jre.jsp and
http://www.physci.org/codes/jretest.jsp?v=12
for further tips..]

What's the URL of your applet?

 

[Steve W. Jackson]

:BTW: I would like to comment that although the possible
:differing versions of Java available on a Mac sounds like a
:confusing headache, I have in the past two weeks found
:that it has been an almost non-existent worry in publicly
:releasing a cross-platform Java app.
:
:A piece of free Java software that I have written has recently
:been "in the news", with the result that either the application
:has been downloaded or the applet version has been viewed
ossibly as much as 100,000 times in two weeks. (I don't have
:the server stats at hand, but I'm serious in saying 100K.)
:
:By far the /biggest/ issue of confusion I have run into
:in answering e-mail during those two weeks has been from
:Windows users who don't understand why the app won't run on
:their computers, at all. Invariably the reason has been that
:they don't have any JRE installed.
:
:Among the Mac users, the only issue has been that a very few
eople have had a version of StuffIt Expander which mangles
:execute permissions when uncompressing a download.

I'm all too familiar with the permission-mangling problem. If you've
got the download in a StuffIt format for those Mac users, you can avoid
all that by stuffing it with the "SITX" format that understands and
keeps those intact. Every version of StuffIt Expander since 5.0, if
memory serves, can handle those files.

= Steve =