Java 7 is at:
JAVA=â/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javaâ
So it will take the current (7) version and launch that before trying JDK 6.
I canât remember now if this is a normal setup or if I changed this manually for some reason to get something else to work (or attempt to work). Java is a pile of steaming manure . If itâs just me then Iâll change the launch script myself to get it to work.
Edit: I checked on my other Mac with 3.2.12-9013 and it launches with Java 6. So I think itâs just what I did to my iMac that is causing this.
I canât remember now if this is a normal setup or if I changed this
manually for some reason to get something else to work (or attempt to
work). Java is a pile of steaming manure :(.
Concur. Iâll be so happy to see the back of it. Itâs the height of
irony that the time I spend dealing with platform-specific issues these
days is mostly involves a language and libraries which are supposedly
platform-independent.
Edit: I checked on my other Mac with 3.2.12-9013 and it launches with
Java 6. So I think itâs just what I did to my iMac that is causing this.
Yes, I suspect that you adjusted the links yourself. I would argue that
Oracleâs Java 7 ought to do that when itâs installed, but as it
doesnât, we have to assume that no one will have these.
Anyway, Iâm happy to know about the CurrentJDK linksâwe now check
there as well, so we shouldnât get any complaints about VASASL not
starting for people with a JDK but no JRE.
Even with that version I get the error message with suggestion I should I install Java SE 6 in spite of having Java 7 already installed.
Vassal 3.2.10 is the latest version working for me at the moment (albeit with terribly laggy scrolling).
Even with that version I get the error message with suggestion I should
I install Java SE 6 in spite of having Java 7 already installed.
Please tell me what all of the symbolic links in your
/System/Library/Frameworks/JavaVM.framework/Versions/ point to. I
canât make any progress without knowing that.
Vassal 3.2.10 is the latest version working for me at the moment (albeit
with terribly laggy scrolling).
Poor graphics performance with Java 7 happens only on some Macs and
isnât our bug, so far as I can see. Itâs also unlikely to be the kind
of thing we can work around. I think itâs likely that itâs Oracleâs
problem, which doesnât make me optimistic that it will be fixed. The
solution I see for this is to use Java 6 until VASSAL 4.
[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/
total 4
0 drwxr-xr-x 8 root wheel 272 10 Nov 19:57 A/
4 lrwxr-xr-x 1 root wheel 1 10 Nov 19:57 Current@ â A
[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/A
total 36
0 drwxr-xr-x 44 root wheel 1496 25 Aug 2013 Commands/
0 drwxr-xr-x 4 root wheel 136 10 Nov 13:45 Frameworks/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013
JavaPluginCocoa.bundle/
36 -rwxr-xr-x 1 root wheel 99792 10 Nov 19:57 JavaVM*
0 drwxr-xr-x 44 root wheel 1496 10 Nov 19:57 Resources/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013 _CodeSignature/
[computer]$
This is with 10.9 fresh installation and just Oracleâs Java 7 JRE
installed.
Oh, thatâs neat. They have Current/Commands/java pointing to something
which tells you that you donât have Java. So NOW YOU CANâT CHECK THAT
TO TELL WHETHER YOU DO! ARGH!
It takes some effort to make it this difficult to determine whether a
program is installed. Apple and Oracle can both go DIAF.
Probably not possible I guess⌠Signing on Linux I mean⌠No chance of
access to a Mac or even a Hackintosh? =)
People have figured out some of the Mac tools. E.g., weâre able to build
a compressed DMG on Linux. Iâm still rather shocked that nobodyâs looked
at what exactly codesign is doing and produced something which does the
equivalent.
We donât happen to have access to a Mac at present, but even if we did,
I wouldnât use it for codesigning. Iâm not interested in having a build
process which canât all be done in one place.
Just out of curiosity, what will Vassal 4 be based on instead of Java?
On a standard, so that clients can be written in anything. The reference
implementation that Iâm planning will be in C++.
If you did it on a Mac you could do all the builds on the Mac .
Although not (yet) required, it will scare off non-pro users if the Mac version of VASSAL 4 is not Gatekeeper signed with an Apple certificate (just as it might scare away people on Windows seeing the unsigned security warning, although they might be more used to clicking away security dialogs).
Just out of curiosity, what will Vassal 4 be based on instead of
Java?
On a standard, so that clients can be written in anything. The
reference
implementation that Iâm planning will be in C++.
Although not (yet) required, it will scare off non-pro users if the Mac
version of VASSAL 4 is not Gatekeeper signed with an Apple certificate
(just as it might scare away people on Windows seeing the unsigned
security warning, although they might be more used to clicking away
security dialogs).
It looks like there is a tool I can use for doing Windows signing,
osslsigncode. What needs to be signedâthe installer? the Java
launcher? Both? Can we use a self-generated certificate?
You can only sign a OS X application for Gatekeeper with an Apple certificate on a Mac. You should sign the bundle (.app package). There is no installer, you donât sign the dmg.
You can only sign a OS X application for Gatekeeper with an Apple
certificate on a Mac. You should sign the bundle (.app package). There
is no installer, you donât sign the dmg.
You must be subscribe as an Apple Mac Developer. Membership is $99/yr. As long as you are a member you get a Developer ID certificate for Gatekeeper and/or App Store distribution (which has also other requirements and restrictions). For non-App Store distribution Apple does not review your software or do any vetting before handing out a Developer ID. If however they find you distribute malware they can revoke your certificate from Gatekeeper to block your software.