mrj.version

Scott Kovatch scott.kovatch at oracle.com
Tue Feb 28 10:07:42 PST 2012


On Feb 28, 2012, at 9:24 AM, Mike Swingler wrote:

> On Feb 28, 2012, at 9:14 AM, Scott Kovatch wrote:
> 
>> Hello,
>> 
>> While doing some applet-related testing we are finding that some applets are still looking for the property mrj.version, and failing to load due to a security exception.
>> 
>> I know that in the past just having it defined was considered enough to know you were running on a Mac, but this is 2012 so I would think looking at 'os.name' and 'java.version' is enough.
>> 
>> I really want to avoid defining it for backwards compatibility because I don't want to attempt to reproduce Apple's versioning conventions. My proposal is that we add mrj.version to the list of 'safe' properties, but don't define it.
>> 
>> Anyone have an opinion on this? Are you using mrj.version in an applet or JNLP-based application? If so, why?
> 
> Kill it, kill it with fire. :-)

Now that's what I call an opinion! 

> I think leaving it undefined is a good approach, however if you find that applets are actually trying to parse the value (which has changed formats several times), I'd suggest using "UNAVAILABLE" or "OBSOLETE" instead of just leaving it an empty string to at least show why the value is there at all (but undefined is still the best option).

So far I've tried one applet that attempts to read the property. When I added in the permissions to allow it to read the property it loaded without any other issues, so based on N=1, I've done all we need to do. :-)

If this comes up again we'll revisit it. I doubt we are breaking much at this point by not having it defined.

-- Scott K.





More information about the macosx-port-dev mailing list