On 9/20/13 5:25 PM, James Wettenhall wrote: > I'm pretty sure that Apple have no interest in supporting Java 7 - > they donated their code to OpenJDK, announced that Java would be > "deprecated" on Mac OS X, and waited for Oracle to announce that they > would provide Java 7 for Mac OS X. But I think Oracle's JRE for Mac > OS X is designed to be used by web browsers. I don't know if an app > bundled with the old JarBundler method will necessarily find the JRE > installed from Oracle.
It won't work with the plugin. I know that already, because my system has the Java 7 plugin but is still using the Java 6 JDK/JRE for running actual apps. However, I'm not sure what you mean by "waited for Oracle to announce that they would provide Java 7 for Mac OS X." Java 7 is available for Mac OS X and has been for some time. The JDK can be downloaded from here: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html and the full-blown JRE (not just the plugin) can be downloaded from here: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html If OpenJDK picks up the ball and runs with it, and if someone provides a nice DMG installer for it, then I would have no qualms about directing users to that. At the moment, however, directing them to Oracle's version seems fine as well. I mean, even if we bundle a JRE, they're going to need to install a separate JRE in order to get JWS functionality, so bundling isn't a panacea. >> From a licensing point of view, are there any potential snafus there? > > Yes I think so. If you want to include an Oracle-built JRE, then I > think you're supposed to display the Oracle binary code agreement. > The OpenJDK source which Oracle uses is available publicly, so maybe > it is legitimate to still license your application as GPL, but some > people (who probably know more about it than me) are of the view that > you need to build your JRE from source if you want to license your app > as GPL, or as GPL with the classpath exception or similar. I tend to take a non-dogmatic, practical view of the GPL, and my view of these matters focuses on intent. The intent of the GPL is to maintain a "pay-it-forward" system. Anyone can reap the benefits of the millions of dollars (in our case, and in the case of many projects) that have been invested into the project, but no one can take the product of that investment and build a solution from it without also allowing everyone else to duplicate their work. Thus, to me, the real litmus test of the GPL is reproducibility. The idea is that, for a given set of infrastructure, the developer should be able to build the application entirely from source, thus allowing him/her to completely back-engineer the application. But the GPL of course doesn't require that the developer be able to build the operating system or the compiler from source. The JRE is a compiler, in a sense, and it's an operating environment in another. The intent of the GPL is to protect both our investment as well as past investment in the project from unfair exploitation, but of course no one involved in this project has invested in the JRE. We've just invested in the VNC viewer application itself. My professional opinion is that, as long as we are not requiring a specific JRE, then the JRE is not a component of our application. It is infrastructure, and thus it does not fall under the scope of the GPL. Even if we bundle a JRE, there is nothing to prevent the user from running the JAR with another JRE of their choosing. A Mac app is a collection of files, not a monolithic binary, and the GPL is clear in Section 2 that "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." However, it goes on to say in Section 3, "the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." It could be argued that the last phrase might mean that bundling a JRE requires distributing the JRE source. I don't agree with that, but I would be interested to read some of the opinions you allude to above. >> Is the JRE such that it requires including the source along with it? > > I don't think there is any such requirement from the JRE, but which > source are you talking about? The .java source files which can be > used to reconstruct the JARs or the C/C++ source which can be used to > build the JRE itself? The source to whatever is bundled in the .app, so I assume both. >> Any sense of the disk footprint? This is also of potential interest for >> Windows and Linux. > > Whilst the words "App Store" might make a GPL developer cringe, it > might be of interest to look at blog posts from Java developers > targeting the App Store, such as: > > http://intransitione.com/blog/take-java-to-app-store/ > > The "Moneydance" application referred to in this article appears to be > 50.7 MB in the App Store, but I haven't purchased it. I would guess > that the majority of that disk footprint is the JRE. That's pretty frickin' huge. :| When you start looking at doing this for multiple platforms and multiple binaries for each platform, then hundreds of megs per release will introduce a lot of problems for me as project maintainer. ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
