Nabble - OpenJDK Modules Discussion

HelloWorld

2009-01-19T02:20:53Z

Hi,

What about the Modules Project ?
I try to get the HelloWorld sample (http://openjdk.java.net/projects/modules/samples.html) but after downloading the openjdk-7-ea-src-b43-15_jan_2009.zip I did not found any src/share/sample/modules/hello-world repository.
Can you help me to find information about the Modules Project ?
Thanks in advance.

SandraB
_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Need help to run java apps on openmoko

2008-10-24T05:55:42Z

Hi,

I am new to openmoko. I want to run one of my java based GUI application on openmoko. But when I tried to check for the java support on the newly brought model, I found there is no java utility pre installed (Any JVM for running java apps). So can you guide me how can I set up my openmoko to run java applications on it? Is there any extra package I need to install? Please guide me, without finding it I can't proceed. Your valuable suggestion will be greatly helpful for me.

Thank you
Regards
Girish
+91 99867 64809

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

FREE Online Test at www.yfrindia.com

2008-09-03T12:20:39Z

http://www.yfrindia.com/
Take FREE online TEST, read FREE articles, download FREE presentation, use FREE source code, useful links, competition updates, free ONLINE TEST TESTS,
http://www.yfrindia.com/resources/Tests
free APTITUDE TEST, English Test, Computer Test, Mechanical Test, Electronics Test, Electrical Test, GATE preparation, CAT preparation, Job preparation, resume.
http://www.yfrindia.com/

Re: [modules-dev] Trying to build the modules stuff

2008-07-29T07:53:26Z

Hi Sam,

> I was able to build the regular JDK 1.7.0 by using an ALT_BOOTDIR with
> JDK 1.6. Is that not the right thing to do? I uncompressed the module
> zip into the jdk directory and tried a clean build

That is correct.

> with this result. Then I tried to use the latest 1.7 binary as the
> ALT_BOOTDIR with the same results.

Ah ok, I tried building the modules*.zip file, I saw several failures,
it looks like
the contents of this file is outdated, I will get to the bottom of this
issue.

Meanwhile, for your purpose you can download the sources without or
with mercurial:

a. without mercurial, you can simply download the latest snapshot from here:
http://hg.openjdk.java.net/jdk7/modules/jdk/archive/tip.zip
which is effectively the same as the modules*.zip bundle you used before.
this will create a jdk-57a05e25caa9, just rename it to jdk.

b. you can also use mercurial to clone only jdk as follows:
% hg fclone http://hg.openjdk.java.net/jdk7/modules/jdk jdk.modules

c. or you can also clone the entire jdk
% hg fclone http://hg.openjdk.java.net/jdk7/modules jdk7
[no need to get the openjdk sources, this contains everything you need]

...and follow your build steps as before, note, you will need to download
the latest openjdk, or you can fclone the entire modules repository, it
contains
everything, if you have already done so, thats fine.

Please let me know if you run into any issues.

Thanks
Kumar

[PS: I am copying modules-discuss in case others run into the same issues].

>
> Sam
>
> On Jul 28, 2008, at 5:20 PM, Kumar Srinivasan wrote:
>
>> Hello Sam,
>>
>> Could you please outline the steps you took to build this.
>>
>> are the sources from the http://hg.openjdk.java.net/jdk7/modules
>> or the modules source drop at:
>> http://www.java.net/download/openjdk/jdk7/promoted/b31/modules-7-ea-src-17_jul_2008.zip
>>
>>
>> Did you build the bootstrap jdk ?
>>
>> Thanks
>> Kumar
>>> Getting javac compiler errors (tried 1.6 and 1.7):
>>>
>>> # Running javac:
>>> /home/sam/jdk1.7.0/bin/java -Xmx874m -Xms128m -XX:PermSize=32m -
>>> XX:MaxPermSize=160m -Xbootclasspath/p:/home/sam/openjdk/build/linux-
>>> amd64/langtools/dist/bootstrap/lib/javac.jar -jar /home/sam/openjdk/
>>> build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -source 1.5 -
>>> target 5 -encoding ascii -Xbootclasspath:/home/sam/openjdk/build/linux-
>>> amd64/classes -sourcepath /home/sam/openjdk/build/linux-amd64/gensrc:/
>>> home/sam/openjdk/jdk/src/solaris/classes:/home/sam/openjdk/jdk/src/
>>> share/classes -d /home/sam/openjdk/build/linux-amd64/classes @/home/
>>> sam/openjdk/build/linux-amd64/tmp/java/java.lang.management/
>>> management/.classes.list
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:69: type parameter
>>> java.lang.management.ClassLoadingMXBean is not within its bound
>>> new MXBeanFetcher<ClassLoadingMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:81: type parameter
>>> java.lang.management.CompilationMXBean is not within its bound
>>> new MXBeanFetcher<CompilationMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:98: type parameter
>>> java.lang.management.MemoryMXBean is not within its bound
>>> new MXBeanFetcher<MemoryMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:110: type parameter
>>> java.lang.management.GarbageCollectorMXBean is not within its bound
>>> new MXBeanFetcher<GarbageCollectorMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:123: type parameter
>>> java.lang.management.MemoryManagerMXBean is not within its bound
>>> new MXBeanFetcher<MemoryManagerMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:136: type parameter
>>> java.lang.management.MemoryPoolMXBean is not within its bound
>>> new MXBeanFetcher<MemoryPoolMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:148: type parameter
>>> java.lang.management.OperatingSystemMXBean is not within its bound
>>> new MXBeanFetcher<OperatingSystemMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:160: type parameter
>>> java.lang.management.RuntimeMXBean is not within its bound
>>> new MXBeanFetcher<RuntimeMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:172: type parameter
>>> java.lang.management.ThreadMXBean is not within its bound
>>> new MXBeanFetcher<ThreadMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:185: type parameter
>>> java.util.logging.LoggingMXBean is not within its bound
>>> new MXBeanFetcher<LoggingMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:199: type parameter
>>> com.sun.management.GarbageCollectorMXBean is not within its bound
>>> new
>>> MXBeanFetcher<com.sun.management.GarbageCollectorMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:212: type parameter
>>> com.sun.management.OperatingSystemMXBean is not within its bound
>>> new MXBeanFetcher<com.sun.management.OperatingSystemMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:224: type parameter
>>> com.sun.management.UnixOperatingSystemMXBean is not within its bound
>>> new MXBeanFetcher<UnixOperatingSystemMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:236: type parameter
>>> com.sun.management.HotSpotDiagnosticMXBean is not within its bound
>>> new MXBeanFetcher<HotSpotDiagnosticMXBean>() {
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/java/lang/management/
>>> PlatformComponent.java:373: cannot find symbol
>>> symbol : method newObjectName(java.lang.String)
>>> location: class com.sun.jmx.mbeanserver.Util
>>> ObjectName on =
>>> com.sun.jmx.mbeanserver.Util.newObjectName(domainAndType);
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/sun/management/
>>> ManagementFactoryHelper.java:223: cannot find symbol
>>> symbol : method newObjectName(java.lang.String)
>>> location: class sun.management.Util
>>> final ObjectName objName = Util.newObjectName(mbeanName);
>>> ^
>>> /home/sam/openjdk/jdk/src/share/classes/sun/management/
>>> ManagementFactoryHelper.java:283: cannot find symbol
>>> symbol : method newObjectName(java.lang.String)
>>> location: class sun.management.Util
>>> final ObjectName objName = Util.newObjectName(mbeanName);
>>> ^
>>> Note: Some input files use or override a deprecated API.
>>> Note: Recompile with -Xlint:deprecation for details.
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> 17 errors
>>> gmake[3]: *** [.compile.classlist] Error 1
>>> gmake[3]: Leaving directory
>>> `/home/sam/openjdk/jdk/make/java/management'
>>> gmake[2]: *** [all] Error 1
>>> gmake[2]: Leaving directory `/home/sam/openjdk/jdk/make/java'
>>> gmake[1]: *** [all] Error 1
>>> gmake[1]: Leaving directory `/home/sam/openjdk/jdk/make'
>>> gmake: *** [jdk-build] Error 2
>>>
>>> real 14m41.320s
>>> user 14m46.341s
>>> sys 2m37.720s
>>>
>>>
>>> _______________________________________________
>>> modules-dev mailing list
>>> modules-dev@...
>>> http://mail.openjdk.java.net/mailman/listinfo/modules-dev
>>>
>>
>>
>> --
>> Kumar Srinivasan
>> Sun Microsystems, Java Software.
>> 408-276-7586
>>
>> _______________________________________________
>> modules-dev mailing list
>> modules-dev@...
>> http://mail.openjdk.java.net/mailman/listinfo/modules-dev
>
>

--
Kumar Srinivasan
Sun Microsystems, Java Software.
408-276-7586

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: How to raise sunbugs?

2008-01-14T18:53:21Z

Glyn Normington wrote:
>
> I can no longer commit time to tracking the JSR 277 mailing list so
> I'd like to formally log the requirement for JSR 277 to interoperate
> with JSR 291 as an enhancement request.

I filed 6650394 to track this. It should become visible at
http://bugs.sun.com/view_bug.do?bug_id=6650394 within a day or two. You
can set a watch there which should ensure that you get an email whenever
there is an update.

Andreas.

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: How to raise sunbugs?

2008-01-10T14:27:21Z

+1

On Jan 10, 2008, at 2:41 PM, Glyn Normington wrote:

> On Jan 10, 2008, at 12:09 PM, Andreas Sterbenz wrote:
>
>> Glyn Normington wrote:
>>> What value of the product/category field should be used when
>>> raising a bug against the modules project?
>>
>> For now it would be easiest to report any bugs or other
>> implementation issues here. The bugs.sun.com mechanism was designed
>> for released products and does not work well for OpenJDK.
>> Eventually we will have a bug database that all community members
>> have full access to, but we are not there yet.
>>
>> Is there something you would like to report?
>>
>> For spec bugs and other issues with the JSR 277 and JSR 294 specs,
>> please continue to use the the JCP feedback channels such as
>> jsr-277-comments@... and jsr-294-comments@... .
>>
>> Andreas.
>>
>
> Hi Andreas
>
> I can no longer commit time to tracking the JSR 277 mailing list so
> I'd like to formally log the requirement for JSR 277 to interoperate
> with JSR 291 as an enhancement request. There are a number of
> benefits of using a bug to do this:
>
> 1. I can subscribe to the bug and know I will be notified if and when
> it is fixed (I will very likely remain interested in the outcome of
> the bug but not in the detailed process in deriving a solution)
> 2. a bug will not float off into obscurity unlike archived mailing
> list threads
> 3. a bug is a good way of tracking the status of "to do" items for
> any project.
>
> This mailing list and the JCP feedback aliases do not provide these
> benefits plus I've already mentioned the interop. issue many times on
> the JSR 277 mailing list and there is still no formal way of tracking
> the progress of the item.
>
> Glyn
> _______________________________________________
> modules-discuss mailing list
> modules-discuss@...
> http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: How to raise sunbugs?

2008-01-10T11:41:23Z

On Jan 10, 2008, at 12:09 PM, Andreas Sterbenz wrote:

> Glyn Normington wrote:
>> What value of the product/category field should be used when
>> raising a bug against the modules project?
>
> For now it would be easiest to report any bugs or other
> implementation issues here. The bugs.sun.com mechanism was designed
> for released products and does not work well for OpenJDK.
> Eventually we will have a bug database that all community members
> have full access to, but we are not there yet.
>
> Is there something you would like to report?
>
> For spec bugs and other issues with the JSR 277 and JSR 294 specs,
> please continue to use the the JCP feedback channels such as
> jsr-277-comments@... and jsr-294-comments@... .
>
> Andreas.
>

Hi Andreas

I can no longer commit time to tracking the JSR 277 mailing list so
I'd like to formally log the requirement for JSR 277 to interoperate
with JSR 291 as an enhancement request. There are a number of
benefits of using a bug to do this:

1. I can subscribe to the bug and know I will be notified if and when
it is fixed (I will very likely remain interested in the outcome of
the bug but not in the detailed process in deriving a solution)
2. a bug will not float off into obscurity unlike archived mailing
list threads
3. a bug is a good way of tracking the status of "to do" items for
any project.

This mailing list and the JCP feedback aliases do not provide these
benefits plus I've already mentioned the interop. issue many times on
the JSR 277 mailing list and there is still no formal way of tracking
the progress of the item.

Glyn
_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: How to raise sunbugs?

2008-01-10T09:09:10Z

Glyn Normington wrote:
> What value of the product/category field should be used when raising
> a bug against the modules project?

For now it would be easiest to report any bugs or other implementation
issues here. The bugs.sun.com mechanism was designed for released products
and does not work well for OpenJDK. Eventually we will have a bug database
that all community members have full access to, but we are not there yet.

Is there something you would like to report?

For spec bugs and other issues with the JSR 277 and JSR 294 specs, please
continue to use the the JCP feedback channels such as
jsr-277-comments@... and jsr-294-comments@... .

Andreas.

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

How to raise sunbugs?

2008-01-09T13:36:28Z

What value of the product/category field should be used when raising
a bug against the modules project?

Thanks,

Glyn
_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: questions on status

2007-11-30T09:35:44Z

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@...
http://www.dpml.net
OpenJDK Discussion <modules-discuss@...>OpenJDK Discussion <modules-discuss@...>OpenJDK Discussion <modules-discuss@...>

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: questions on status

2007-11-28T16:42:42Z

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
_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Launching JAM modules

2007-11-21T11:19:55Z

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.
_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

Re: questions on status

2007-10-24T03:16:58Z

Hi Stephen,

I'm looking into the licensing issue. I've been mostly offline last week
and this week, and will follow up your questions when I'm back in office.

- Stanley

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?
>
> (b) Will the interoperability strawman be subject to the same
> closed review process or can we expect imminent publication
> without legal constraint?
>
> (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?
>
> (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.
>
> Cheers, Steve.
>
>
> On Fri, 2007-09-07 at 13:27 +0930, Stanley M. Ho wrote:
>> Hi Glyn,
>>
>> The work is in progress, and there are ongoing prototypings to figure
>> out how it should work and to also validate the overall approach. I
>> will send out the strawman proposal for the EG to review and discuss
>> when it is ready. Interoperability is definitely something that I
>> would like to address before this JSR goes public review.
>>
>> - Stanley
>>
>>
>> Glyn Normington wrote:
>>> Hi Stanley
>>>
>>> Please could you provide an update on your work on interoperation
>>> between JSR 277 and JSR 291?
>>>
>>> If the work is still in progress, how's it coming along and roughly
>> when
>>> might there be a strawman proposal to review?
>>>
>>> Thanks,
>>>
>>> Glyn
>
>

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss

questions on status

2007-10-13T15:03:20Z

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?

(b) Will the interoperability strawman be subject to the same
closed review process or can we expect imminent publication
without legal constraint?

(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?

(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.

Cheers, Steve.

On Fri, 2007-09-07 at 13:27 +0930, Stanley M. Ho wrote:

> Hi Glyn,
>
> The work is in progress, and there are ongoing prototypings to figure
> out how it should work and to also validate the overall approach. I
> will send out the strawman proposal for the EG to review and discuss
> when it is ready. Interoperability is definitely something that I
> would like to address before this JSR goes public review.
>
> - Stanley
>
>
> Glyn Normington wrote:
> >
> > Hi Stanley
> >
> > Please could you provide an update on your work on interoperation
> > between JSR 277 and JSR 291?
> >
> > If the work is still in progress, how's it coming along and roughly
> when
> > might there be a strawman proposal to review?
> >
> > Thanks,
> >
> > Glyn
>

--
Stephen J. McConnell
mailto:mcconnell@...
http://www.dpml.net

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss