4 ms·

Can you please name some examples for "business based on a Mac Java apps?" Especially those that don't use OSX specifics. I don't understand this question. Ei

Can you please name some examples for "business based on a Mac Java apps?" Especially those that don't use OSX specifics. I don't understand this question. Either it's a Java app (no platform specified), or it's a Mac Java app that does use OSX-specific code.

acqq 16y ago
Microsoft was sued by Sun because of "a deliberate course of conduct to fragment Java" and had to settle by removing their own Java implementation from the operating system. http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit.html http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit.... http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine As far as I understand Java license doesn't allow you to make a platform specific Java implementation. So who's then to bet his business on Mac Java apps? The only potentially "safe" approach is not to depend on Mac specifics. But is there any example of a profitable Java app (which made profit by targeting OSX customers) applying the mentioned "safe" approach?
- pmjordan 16y ago
  They got sued for not adhering to the Java spec, not for their extensions. The latter would be ridiculous, it would mean you could never distribute the JRE together with any sort of extra libraries. Even the Sun/Oracle runtime ships with non-standard extensions (javax.* , com.sun.*).
  - acqq 16y ago
    > not adhering to the Java spec, not for their extensions. And AFAIK specs are made for "write once run everywhere." > it would mean you could never distribute the JRE together with any sort of extra libraries. You can as long as you are using only what Sun (now Oracle) approves. > Even the Sun/Oracle runtime ships with non-standard extensions They make the rules, so what they do can't be used as an argument.
    - pmjordan 16y ago
      And AFAIK specs are made for "write once run everywhere." Yes, my understanding was that the MS implementation did not pass all the compatibility requirements. Adding extra functionality is entirely orthogonal to that point. IBM's, Azure's and all the J2ME implementations come with proprietary extensions and are blessed by Sun/Oracle. I don't follow your argument.
      - acqq 16y ago
        > and are blessed by Sun/Oracle. I don't follow your argument I don't have anything more to add than to quote you (the keyword is blessed) and also point to my previous posts. As long as you're forced to get the blessing before you introduce the interface to your own platform (or be forced to leave something out because you know it won't be blessed) why should it be in your interest to maintain the technology of others if you have your own technologies and a platform that's attractive even by itself?
        pmjordan 16y ago
        From my own experience with it: - .class files compiled on Apple's JVM work fine on other JVMs - Source code written for Apple's version of javac will compile fine on other Java compilers. To my knowledge, Microsoft's JVM violated both of these requirements, which was Sun's bone of contention. (Android's Dalvik is in similar violation, but doesn't pretend to be "Java" - they're being sued based on patents IIRC)
        acqq 16y ago
        > .class files compiled on Apple's JVM work fine on other JVMs Technically, you don't need to compile "on JVM" but "for JVM." And it doesn't seem to be as you describe for most of the cases (in Sun's words, 98%). > Microsoft's JVM violated both of these requirements AFAI understand it was far more subtle: the language (the source form representation) was extended with the features which functioned only on Microsoft's implementation, and only such classes were affected. See http://download.oracle.com/javase/1.4.2/docs/guide/deployment/deployment-guide/upgrade-guide/ http://download.oracle.com/javase/1.4.2/docs/guide/deploymen... for a list of issues of switching from Microsoft VM based upon Java 1.1 to Sun's 1.4.2. The list appears to be very unimpressive.

acqq 16y ago

Microsoft was sued by Sun because of "a deliberate course of conduct to fragment Java" and had to settle by removing their own Java implementation from the operating system. http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit.html http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit.... http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine As far as I understand Java license doesn't allow you to make a platform specific Java implementation. So who's then to bet his business on Mac Java apps? The only potentially "safe" approach is not to depend on Mac specifics. But is there any example of a profitable Java app (which made profit by targeting OSX customers) applying the mentioned "safe" approach?

pmjordan 16y ago
They got sued for not adhering to the Java spec, not for their extensions. The latter would be ridiculous, it would mean you could never distribute the JRE together with any sort of extra libraries. Even the Sun/Oracle runtime ships with non-standard extensions (javax.* , com.sun.*).
- acqq 16y ago
  > not adhering to the Java spec, not for their extensions. And AFAIK specs are made for "write once run everywhere." > it would mean you could never distribute the JRE together with any sort of extra libraries. You can as long as you are using only what Sun (now Oracle) approves. > Even the Sun/Oracle runtime ships with non-standard extensions They make the rules, so what they do can't be used as an argument.
  - pmjordan 16y ago
    And AFAIK specs are made for "write once run everywhere." Yes, my understanding was that the MS implementation did not pass all the compatibility requirements. Adding extra functionality is entirely orthogonal to that point. IBM's, Azure's and all the J2ME implementations come with proprietary extensions and are blessed by Sun/Oracle. I don't follow your argument.
    - acqq 16y ago
      > and are blessed by Sun/Oracle. I don't follow your argument I don't have anything more to add than to quote you (the keyword is blessed) and also point to my previous posts. As long as you're forced to get the blessing before you introduce the interface to your own platform (or be forced to leave something out because you know it won't be blessed) why should it be in your interest to maintain the technology of others if you have your own technologies and a platform that's attractive even by itself?
      - pmjordan 16y ago
        From my own experience with it: - .class files compiled on Apple's JVM work fine on other JVMs - Source code written for Apple's version of javac will compile fine on other Java compilers. To my knowledge, Microsoft's JVM violated both of these requirements, which was Sun's bone of contention. (Android's Dalvik is in similar violation, but doesn't pretend to be "Java" - they're being sued based on patents IIRC)
        acqq 16y ago
        > .class files compiled on Apple's JVM work fine on other JVMs Technically, you don't need to compile "on JVM" but "for JVM." And it doesn't seem to be as you describe for most of the cases (in Sun's words, 98%). > Microsoft's JVM violated both of these requirements AFAI understand it was far more subtle: the language (the source form representation) was extended with the features which functioned only on Microsoft's implementation, and only such classes were affected. See http://download.oracle.com/javase/1.4.2/docs/guide/deployment/deployment-guide/upgrade-guide/ http://download.oracle.com/javase/1.4.2/docs/guide/deploymen... for a list of issues of switching from Microsoft VM based upon Java 1.1 to Sun's 1.4.2. The list appears to be very unimpressive.