From mburton at niskala.org Wed Nov 21 11:19:55 2007 From: mburton at niskala.org (Michael Burton) Date: Wed, 21 Nov 2007 11:19:55 -0800 Subject: [modules-discuss] Launching JAM modules Message-ID: <8292D7B4-71E5-49D6-A2D0-FF10AF51187F@niskala.org> After being distracted with real life for a few months, I came back to http://openjdk.java.net/projects/modules/ and was impressed with the recent progress made on the modules project. This has motivated me to ask a question that's been on my mind for a few major releases of java now. Have there been discussions concerning alternate, perhaps more convenient mechanisms to launch JAM (and jar) files? It appears that the currently supported mechanisms use the "java -jam" launcher or a variant thereof, which is a very consistent solution but has a couple of shortcomings. Since java's inception, the burden has been on the user to know the myriad of configuration necessary to launch a java jar file [1]. At a minimum they must know which java to use - 1.4.2? 1.5? 1.6? [2] Frequently though, they must also know what classpath to configure, or what heap size to set, or what platform-specific properties the application might require. It's because of this that most java applications [3] ship with several platform-specific scripts to launch the application. Most of these scripts go through exactly the same contortions: find java, find the jar file, set the heap-size and some OS-specific options, then launch the application. This has always made java a second-class citizen on most OSs, at least in my mind. Running a java application is not nearly as intuitive as running a native application[4] for the typical user, but really it could be. With Modules, the requirement to set the classpath mostly goes away, but things like heap size, java version, and java properties are still very necessary. There are probably various solutions to this problem, but one that comes to mind is a simple descriptor packaged in the archive[5] which could be read by a pre-java launcher that could launch the appropriate version of java with the correct command line options [6]. Pair this with platform-specific bindings (eg. using "#!/bin/javalauncher" for POSIX [7], file type mappings for double-clicking on windows, mac, KDE, etc) to associate JAM files with the launcher, and all of a sudden we no longer need to ship launcher scripts with our java applications. Thanks Michael Burton [1] Or if not the user, then the packager must supply scripts that do this for them. [2] Or hope that their system default is compatible with the jar application they're trying to run. [3] Ant, maven, tomcat, jboss, intellij, to name a few that I use frequently. [4] Or even as running a simple shell/python/ruby script. Complex multi-file scripts are another story. [5] Perhaps the mainfest file? [6] This is more or less the sort of thing that JNLP tackles on the web. [7] It might be tempting to try to use "#!/bin/java -jam" instead of a separate java launcher, but passing additional arguments like -jam to the executable will not work on all UN*X variants, and the path to the java executable is not standardized across environments. From Stanley.Ho at Sun.COM Wed Nov 28 16:42:42 2007 From: Stanley.Ho at Sun.COM (Stanley M. Ho) Date: Wed, 28 Nov 2007 16:42:42 -0800 Subject: [modules-discuss] questions on status In-Reply-To: <471F0D8A.60508@sun.com> References: <1189284179.6213.188.camel@gloria> <1192309400.5956.47.camel@gloria> <471F0D8A.60508@sun.com> Message-ID: <474E0B02.3090509@sun.com> Hi Steve, I have been on family leave on and off in the last few weeks, and I apologize that this reply took much longer than I would like. > Stephen J. McConnell wrote: >> To the 277 community at large: >> >> Some questions on status: >> >> (a) The comments below reference a pending strawman document, >> however, about 5 months ago another strawman document was >> referenced (the service and service provider support >> document) but that document was restricted to EG members >> pending Sanley Ho's resolution of JCP rules via a request for >> clarification to the JCP PMO. I would like to know if >> the JCP PMO raised any issues that would prevent publication, >> and if so, what those issues were? Although the code is developed on OpenJDK under GPL, the spec (including the strawman) is developed in the JCP under a different license. To release this strawman to the public, it will come with a license. It can either be made available on the JSR community page on jcp.org, or on openjdk.java.net. However, the former would mean that the strawman is only accessible by JCP members because it will require login, and I don't think this is what we want. Alternatively, in the latter case, the strawman will require a click-through license mechanism in place. This is the option I am leaning towards, and we've been waiting for the mechanism to be ready. >> (b) Will the interoperability strawman be subject to the same >> closed review process or can we expect imminent publication >> without legal constraint? The interoperability strawman will be subjected to the same process. >> (c) Have any actions been taken to eliminate the requirement >> for people interested in JSR 277 to accept the license >> constraints associated with the initial draft specification >> document (this has been and remains an issue in terms of >> engaging a broader FOSS community in the evaluation of the >> 277 work)? In particular - can be look forward to the >> publication of the second edition of the draft specification >> under the GPL? This is the way things have been so far. Onno Kluyt in JCP PMO has recently started a new round of discussion on this with our fine legal minds, and the discussion is ongoing. It is unlikely that there will be changes in this aspect in the second EDR, but I can't say for sure for future editions of the spec down the road. >> (d) Is anyone on the 277 EG working with the IcedTea project >> to establish an installable modules prototype? In my opinion >> a working distribution of the modules system would be very >> valuable and generate a greater level of community >> involvement. We're not aware any EG member working with IcedTea at this point. That said, we hope the community would involve and start the effort if this is important to the community. That's the purpose of open source after all! - Stanley From mcconnell at dpml.net Fri Nov 30 09:35:44 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Sat, 01 Dec 2007 04:05:44 +1030 Subject: [modules-discuss] questions on status In-Reply-To: <474E0B02.3090509@sun.com> References: <1189284179.6213.188.camel@gloria> <1192309400.5956.47.camel@gloria> <471F0D8A.60508@sun.com> <474E0B02.3090509@sun.com> Message-ID: <1196444144.11731.76.camel@gloria> On Wed, 2007-11-28 at 16:42 -0800, Stanley M. Ho wrote: > Hi Steve, > > I have been on family leave on and off in the last few weeks, and I > apologize that this reply took much longer than I would like. > > > Stephen J. McConnell wrote: > >> To the 277 community at large: > >> > >> Some questions on status: > >> > >> (a) The comments below reference a pending strawman document, > >> however, about 5 months ago another strawman document was > >> referenced (the service and service provider support > >> document) but that document was restricted to EG members > >> pending Sanley Ho's resolution of JCP rules via a request for > >> clarification to the JCP PMO. I would like to know if > >> the JCP PMO raised any issues that would prevent publication, > >> and if so, what those issues were? > > Although the code is developed on OpenJDK under GPL, the spec (including > the strawman) is developed in the JCP under a different license. To > release this strawman to the public, it will come with a license. It can > either be made available on the JSR community page on jcp.org, or on > openjdk.java.net. However, the former would mean that the strawman is > only accessible by JCP members because it will require login, and I > don't think this is what we want. This option is viable assuming login conditions do not impose unreasonable conditions on the contributions or potential actions of contributors - however - if I understand correctly this option correctly we are talking about the addition of members to the expert group and given earlier discussion on this subject I'm presuming this is not an option (even though the expert group have been resounding silent with respect to technical opinion in the last few months). Perhaps some culling and rejuvenation is needed? Clearly there has been the blitz by the OSGI community but to be frank - it hasn't been backed up by technical argument (on the service management side of the equation) - but more to the point there has been next to nothing from the members representing Maven or Ivy (but if you do some digging its reasonable to assume that both of these communities are following the process as opposed to contributing to the questions of effective repository management). But this is only scraping the surface (take the underwhelming contribution of the ASF as an example). To get the point: a) you have an expert group composed of members with vested interests for the most part are waiting in the wings to see what you and your team can come up with (largely because none of them can claim the moral high ground on this subject) b) an internal development team are pushing content into the OpenJDK process that is dealing with the public content but at the same time specifically ignoring the "JCP private content" (e.g. nothing in the code base for service loader that deals with 277) - and no discussion on this within OpenJDJ lists - but wait a sec - this is because of the licensing issues? The 294 project published its ideas (strawman documents) to the public without recourse to an internal "legal team" or was that just an anomaly? > Alternatively, in the latter case, the > strawman will require a click-through license mechanism in place. This > is the option I am leaning towards, and we've been waiting for the > mechanism to be ready. My position is that I don't want to be presented with inhibitors to my own objectives. I am working on applications that have a direct and immediate impact on 20 million people. I know that a solution dealing with modularisation will have a significant impact on service delivery. Things we do will save many lives. In offline communications from several months ago I have comments to imminent resolution to the click-though theme - sorry - but this is not sufficient. Either give me a real and tangible deadline or give me the name and email address of the person responsible. > > >> (b) Will the interoperability strawman be subject to the same > >> closed review process or can we expect imminent publication > >> without legal constraint? > > The interoperability strawman will be subjected to the same process. I should note my personal priorities - I have zero interest in the interoperability question (and it was not a subject of the initial JSR). What I want to see is the real working solution. I should note that given the absence of comments in the public over the last couple of months I'm assuming that a fight is ensuing under private lists. If this is true - then do the rest of us a favour and kill the process and force the discussion into the public domain. I know I have a few thought of my own that I could add to the process. > >> (c) Have any actions been taken to eliminate the requirement > >> for people interested in JSR 277 to accept the license > >> constraints associated with the initial draft specification > >> document (this has been and remains an issue in terms of > >> engaging a broader FOSS community in the evaluation of the > >> 277 work)? In particular - can be look forward to the > >> publication of the second edition of the draft specification > >> under the GPL? > > This is the way things have been so far. Onno Kluyt in JCP PMO has > recently started a new round of discussion on this with our fine legal > minds, and the discussion is ongoing. It is unlikely that there will be > changes in this aspect in the second EDR, but I can't say for sure for > future editions of the spec down the road. When it comes to matter of legality - I am not out of my depth. Could you please ask Onno Kluyt to contact me directly (or even better - get Onno Kluyt to post his opinions to this list directly). This is the OpenJDK and for better or worse - this is an open process. Frankly - this 'open-theme' is not something that earlier JCP initiatives had to deal with - but it is a reality now. What I want is ideas, scratch-pad initiatives, opinions (for and against), code as the basis of argument, and at the end of the day "anything published is fair gaim" (and to be specific here - what I mean is that anything published under GPL is there for the taking, change and publication of alternative realities). > >> (d) Is anyone on the 277 EG working with the IcedTea project > >> to establish an installable modules prototype? In my opinion > >> a working distribution of the modules system would be very > >> valuable and generate a greater level of community > >> involvement. > > We're not aware any EG member working with IcedTea at this point. That > said, we hope the community would involve and start the effort if this > is important to the community. That's the purpose of open source after all! According to my analysis the vast majority of code dealing with 294 and 277 can be compiled against SE6. This would imply that we (the real world community) could (in theory) build and compile a deployment platform based on the 294/277 ideas. In practise the 294 solution is not yet in place (real specs not in place yet but there is promise if we are optimistic about recent posts on relevant lists). The 277 stuff is a little more painful because it ties us in to native solutions with the java command line - but in reality this is academic - the reality is that we should be able top run up a 277 solution of SE6 (but nothing in the codebase is enabling this scenario). Rapping up: I've been communicating with 277 member since 2005. Its now 2007 and on one hand there has been a lot of progress - the draft spec and the OpenJDK Modules codebase. During that period I have watched a lot of hummis from the OSGI community (but not a lot of substance). I have watched a lot of ducking and weaving on the JCP side of things. I have not seen anything on the service deployment model aside from announcements of private documents. Stanley - it ain't good enough. I want code, I want justification, I want opposing opinion. /Steve. > - Stanley -- Stephen J. McConnell mailto:mcconnell at dpml.net http://www.dpml.net OpenJDK Discussion OpenJDK Discussion OpenJDK Discussion