Fixed DisplaySystem to use java.util classes


//MSLI:
import java.util.ServiceConfigurationError;
import java.util.ServiceLoader;
//import sun.misc.Service;
//import sun.misc.ServiceConfigurationError;
//:MSLI

=========

    private static Map<String, SystemProvider> getSystemProviderMap()
            throws ServiceConfigurationError {
        if (systemProviderMap.isEmpty()) {
//MSLI:
//            @SuppressWarnings("unchecked")
            ServiceLoader<SystemProvider> loader = ServiceLoader.load(SystemProvider.class);
            Iterator<SystemProvider> displayProviders = loader.iterator();
//            Iterator<SystemProvider> displayProviders = Service.providers(SystemProvider.class);
//:MSLI
            while (displayProviders.hasNext()) {
                SystemProvider provider = (SystemProvider) displayProviders
                        .next();
                systemProviderMap.put(provider.getProviderIdentifier(),
                        provider);
            }

Can you provide a diff?



thank you :wink:

fwiw, this means the code base will have to become dependent on Java 6 (which will make it challenging for 32 bit mac users)

fwiw, this means the code base will have to become dependent on Java 6 (which will make it challenging for 32 bit mac users)


That's bad.

jonbarril: What's the reason you suggested this change?

In a nutshell: veni, vidi, vici.



I was fixing something else in JME.  When I tried to get the source compiled I saw that it was dependent on some com.sun stuff.  With a bit of googling it was apparent that Sun had moved it into java.util and the fix was an easy one.  I was not aware that this was a Java 6/Mac always-behind-the-old-cow's-tail issue.



As for Java and the Mac, I too have been plagued off and on by this ongoing "problem" for years – trying to do development with one hand tied behind my back.  That is one of the reasons that I was glad to get off of the Mac for development.  That said, for the app I'm currently working on I will eventually have to be able to support the Mac, and for that I appreciate you guys wanting to keep the platform truly cross platform.

who knows, maybe oracle cares more about apple users, but i doubt it :wink:

Why has your fix not already been submitted?

renanse said:

fwiw, this means the code base will have to become dependent on Java 6 (which will make it challenging for 32 bit mac users)


The code needs to be Java 5 Compatible.
Core-Dump said:

renanse said:

fwiw, this means the code base will have to become dependent on Java 6 (which will make it challenging for 32 bit mac users)


The code needs to be Java 5 Compatible.

Ok it means that I will have to avoid using Java 6 features for new features of JME 2.