headers
Tom Brito | 10 May 14:56
Picon
Gravatar

Is com.sun.org.apache same as org.apache package?

-- Wellington B. de Carvalho

_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss
Permalink | Reply | 0 comments |
headers
Sandra Bogaert | 19 Jan 11:20
Picon

HelloWorld

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
Permalink | Reply | 0 comments |
headers
Girish Revadigar | 24 Oct 14:55
Picon

Need help to run java apps on openmoko

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
Permalink | Reply | 0 comments |
headers
Kumar Srinivasan | 29 Jul 16:53
Picon

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

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
Permalink | Reply | 0 comments |
headers
Glyn Normington | 9 Jan 22:36
Favicon

How to raise sunbugs?

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

Thanks,

Glyn
Permalink | Reply | 4 comments |
headers
Michael Burton | 21 Nov 20:19

Launching JAM modules

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.
Permalink | Reply | 0 comments |
headers
Stephen J. McConnell | 13 Oct 23:03

questions on status


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
Permalink | Reply | 3 comments |
headers
Tom Marble | 19 Sep 17:33
Picon

Test of Gmane

Hi:

This is a test message.

If all goes well this message will soon appear in:
http://gmane.org/info.php?group=gmane.comp.java.openjdk.modules.general

Regards,

--Tom
Permalink | Reply | 0 comments |

Gmane