From dalibor.topic at googlemail.com Sat Dec 1 08:08:57 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Sat, 1 Dec 2007 17:08:57 +0100 Subject: processes, goals, infra Message-ID: <985bee770712010808i216134cs7c0417dae132d41c@mail.gmail.com> We've got the group instantiated now, so, as Emmanuel asked how this should work, I thought I should start a separate thread on all that, so that we can bundle our discussion and ideas. First of all, goals. I think there are two main areas where this group should be active in, from our discussions on the discuss at openjdk mailing lists over the past weeks: 1) bringing in existing and new (Open)JDK ports into the OpenJDK community 2) providing a forum for porters to exchange experiences, code & information The forum part would be this mailing list, and anything else people want to contribute in terms of porting documentation, etc. For the other part, most developers who have expressed interest in the porters group, afaict, have the implicit goal to have their port merged into the OpenJDK upstream properly, so that Java 7 can support it out of the box. That means that their own ports need to have a place to develop & seed their contributions, fixes etc. into OpenJDK. I think the best way to do that is to have porting projects being sponsored by this group, per discussion we had on the discuss mailing list. So, an existing porting project would send in a proposal for their port to become part of the OpenJDK community, and the members of this group would then vote on sponsoring it within two weeks of the proposal. A porting project would than, provided the majority of the members vote for the proposal, be instituted, and get its own piece of common infrastructure on OpenJDK (list, mercurial, etc.) and could start to populate their project's repository with their code, apply for an OpenJDK TCK license, etc. The typical proposal could look something like http://mail.openjdk.java.net/pipermail/announce/2007-October/000016.html , adapted for a port, rather than a hotspot extension, i.e. please tell us who you are, what platform you are porting OpenJDK to, if the code exists, where to find it, and what your plans & goals are. If you are unsure about something, you can ask about it here, or on the #openjdk IRC channel on irc.oftc.net. Once the proposal passes the vote, the corresponding porting project would get set up within OpenJDK, with its own mailing list(s), mercurial repository and web presence. For code going into the repositories hosted by the OpenJDK project, the same rules would apply for porting projects as for any other projects: the code needs to be covered by the SCA. Beside all the CYA legal reasons to avoid problems later, there is a practical reason for that: for patches coming from ports to be merged into the main OpenJDK project, the authors of the patches need to have signed the SCA, so as I expect that the goal of the most porting projects is to get their changes merged upstream into jdk7, it makes more sense to do the SCA signing dance once per author, than to have to repeatedly track down authors for each patch going upstream. The other pragmatic reason is that it allows the code coming from JRL or SCSL licensed ports to be re-licensed under OpenJDK's licenses by Sun as they get to share the copyright on it. For third-party code that means: please don't upload it into a project's repository without discussing it here first. From a software engineering perspective, bundling third party code ofter turns out to be a maintenance nightmare (been there, done that with Kaffe.org & GNU Classpath), so whenever possible, please avoid checking in third party JARs, sources, etc. into your project's repository, and use more suitable ways for your platform to ensure that such third party code is available to the port. For example, you could make sure that it is packaged for your platform of choice, and document the procedure to get such build or runtime dependencies installed in the project's documentation. cheers, dalibor topic From dalibor.topic at googlemail.com Sat Dec 1 08:15:04 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Sat, 1 Dec 2007 17:15:04 +0100 Subject: mac.javazone.org forum In-Reply-To: References: <47505C3F.1040109@Sun.COM> Message-ID: <985bee770712010815j70bd6fb6ibea134fbde65071f@mail.gmail.com> On Nov 30, 2007 9:10 PM, Emmanuel Puybaret wrote: > Hi, > > Vijay Kiran Duvvuri created a forum http://mac.javazone.org/forum/ > about Java port (see his message at > http://lists.apple.com/archives/Java-dev/2007/Nov/msg00681.html ). > > This is a nice idea, but I'm wondering if doubling the places where we can > talk about Java port is very effective at this time (even if Vijay's forum > is more dedicated to Mac OS X). What's you mind about this ? > I'd expect this particular list to be primarily concerned with ongoing development of ports, rather than end user support for a specific port. Once we set up a porting project as part of OpenJDK, the authors can decide how they'd like to run it, of course, and where to host which parts of the project's infrastructure, just like it's working now. In general, the more information is out there, the merrier, in my opinion. cheers, dalibor topic From dalibor.topic at googlemail.com Sat Dec 1 08:29:27 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Sat, 1 Dec 2007 17:29:27 +0100 Subject: Introduction Message-ID: <985bee770712010829s32664654l2275efef4e078629@mail.gmail.com> Hi porters, I'm Dalibor Topic, the current co-maintainer of the Kaffe virtual machine, sharing the duty with Jim Pick. My own interest in the porters group is to help existing and new (community) ports of (Open)JDK merge into the OpenJDK community and aid them in getting set up and running, as well as to work with together other VMs that desire to reuse parts of significant parts of OpenJDK. cheers, dalibor topic From landonf at bikemonkey.org Sat Dec 1 12:11:21 2007 From: landonf at bikemonkey.org (Landon Fuller) Date: Sat, 1 Dec 2007 12:11:21 -0800 Subject: My Introduction Message-ID: Hi all, By day I work here in San Francisco for Three Rings Design (www.threerings.net ). I am a commiter on (and a minor contributor to) the FreeBSD Java project. I have been working in my own time to add Mac OS X support to the BSD code base, and have published the SoyLatte release of Java 6 based on this work: http://landonf.bikemonkey.org/static/soylatte/ http://landonf.bikemonkey.org/code/macosx/ SoyLatte is a staging ground for the Mac OS X port -- it is not intended to be a fork of the BSD sources, and I've been diligent in merging changes upstream to the BSD repository as they stabilize. The SoyLatte port is currently very stable. It's my goal to gradually incorporate additional Mac OS X-specific functionality into SoyLatte, such as: - An aqua look and feel, working with Werner Randelshofer to integrate Quaqua as the system L&F (http://www.randelshofer.ch/quaqua/download.html ) - Native AWT Toolkit for Mac OS X (I've begun implementation) - Integrating with the Mac OS X x509 certificate store. - Working with the other ports on a sound implementation (eg, using PortAudio, or ...) I expect the native GUI issues to be particularly time consuming, especially given my lack of familiarity with GUI development on Mac OS X. Additionally, I would also like to work on some Hotspot changes in coordination with the Hotspot developers: - 16-byte stack alignment on x86_32 systems (http://landonf.bikemonkey.org/static/code/java/patch-stack-align-darwin-v2 ) - Minor 16-byte stack alignment issues on the x86_64 (calls generated from hotspot/src/cpu/amd64/vm/sharedRuntime_amd64.cpp are not always aligned) Lastly, I am very excited about the possibility of working with other porters to implement PowerPC support for BSD/Mac OS X. Looking forward to collaborating! -landonf From werner.randelshofer at bluewin.ch Sun Dec 2 03:37:52 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Sun, 2 Dec 2007 12:37:52 +0100 Subject: Introduction Message-ID: Dear porters, I am Werner Randelshofer, the maintainer of the Quaqua Look and Feel for Mac OS X. My interest is to get a good compliance of Open JDK with the Apple Human Interface Guidelines. With Quaqua I currently have partial implementations of various designs of the Aqua interface: Jaguar, Panther, Tiger and Leopard. The most complete implementation being Tiger. Quaqua 'borrows' missing interface elements from the AquaLookAndFeel by Apple and make use of some other platform-specific features of Apple's Macintosh Runtime for Java (MRJ). Currently, Quaqua runs on Mac OS 10.3 through 10.5 with Apple's MRJ for 1.4, 1.5 and 1.6. (I just recently dropped support for Apple's MRJ for Java 1.3, because Apple dropped this JVM on Mac OX 10.5.) With the latest code changes that I made, Quaqua runs also with the SoyLatte port of Java 6 for Mac OS X by Landon Fuller. With best regards, Werner From werner.randelshofer at bluewin.ch Sun Dec 2 05:52:57 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Sun, 2 Dec 2007 14:52:57 +0100 Subject: Feasibility of integrating an Aqua interface Message-ID: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> Dear readers, I am seeking advice for the feasibility of integrating an Aqua interface into OpenJDK. Are there any legal limitations which could prevent an integration of an Aqua interface into OpenJDK? Except for having to restrict end user usage of the Aqua interface to Mac OS X, there appear to be no other limitations imposed by Apple Inc. which are legally binding. (At least not in my jurisdiction which is Switzerland). After all, there is a Windows Look and Feel in OpenJDK with no more limitations than this. But maybe Sun entered a special license agreement with Microsoft for this. (?) Would it be desirable to include the source code of the Quaqua look and feel into OpenJDK? Quaqua is currently a Java specification independent and JVM- independent look and feel. It can run on Java 1.4 through 1.6. It can run on Apple's MRJ and on Landon Fuller's SoyLatte. Only a subset of Quaqua would be needed for a specific OpenJDK port. Quaqua contains a substantial number of artwork copyrighted by Apple, Inc. This is no problem in my jurisdiction, but it might be for other jurisdictions. After all, there is a very marginal number of artwork copyrighted by Microsoft in OpenJDK as well (namely some filesystem icons). How should we proceed with the integration of an Aqua interface into SoyLatte? Should we integrate the source code of Quaqua into SoyLatte, or should we integrate Quaqua binaries as a internal or external build dependency, or rather only as an internal or external runtime dependency? Dalibor Topic recommended on Sat Dec 1 08:08:57 PST 2007 in the thread "processes, goals, infra" to not include third party libraries without considering the consequences that this might have: > For third-party code that means: please don't upload it into a > project's repository without > discussing it here first. From a software engineering perspective, > bundling third party code > ofter turns out to be a maintenance nightmare (been there, done that > with Kaffe.org & > GNU Classpath), so whenever possible, please avoid checking in third > party JARs, sources, > etc. into your project's repository, and use more suitable ways for > your platform to ensure > that such third party code is available to the port. For example, > you could make > sure that it is packaged for your platform of choice, and document the > procedure to get > such build or runtime dependencies installed in the project's > documentation. After reading Dalibor's advice, I think it might be sensible to include Quaqua only as an external build dependency into SoyLatte? With best regards, Werner From landonf at bikemonkey.org Sun Dec 2 11:20:28 2007 From: landonf at bikemonkey.org (Landon Fuller) Date: Sun, 2 Dec 2007 11:20:28 -0800 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> Message-ID: On Dec 2, 2007, at 5:52 AM, Werner Randelshofer wrote: > Except for having to restrict end user usage of the Aqua interface > to Mac OS X, there appear to be no other limitations imposed by > Apple Inc. which are legally binding. (At least not in my > jurisdiction which is Switzerland). > After all, there is a Windows Look and Feel in OpenJDK with no more > limitations than this. But maybe Sun entered a special license > agreement with Microsoft for this. (?) Hi Werner -- Google's drawing a blank -- do you know where I can find the license terms for Apple's Aqua artwork? Thanks! Landon From werner.randelshofer at bluewin.ch Sun Dec 2 12:09:48 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Sun, 2 Dec 2007 21:09:48 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> Message-ID: <53B0A25A-1ADF-4F28-89F2-1D8877CC1AD6@bluewin.ch> Hi Landon, There are none - that's exactly my point - Apple does not license their artwork to third parties. That's why we must restrict usage of the Aqua interface in OpenJDK to Mac OS X. There is a developer license program for some of Apple's products, as well as for some logos and badges here: http://developer.apple.com/softwarelicensing/ Aqua can not be licensed here. Here is what Apple has to say about licensing in general: "Regardless of whether your product will be sold, used internally, or bundled with other products, if you wish to use Apple software and/or technologies, you need to obtain a license from Apple to do so. Apple's Software Licensing Department works with developers, user groups, and others to ensure they are properly licensed for many of Apple technologies." And here is the licensing FAQ page: http://developer.apple.com/faq/softwarelicensing.html Here is the first FAQ question: "1. Who needs to be licensed? If you use all or part of any Apple software in a program that will be distributed to other people, you need to license the use of that software from Apple Computer, Inc. Apple Trademarks must also be licensed for use. This is true whether the product will be sold, used internally,or given away. It's true for commercial vendors and educators. It's true for old, new, and future Apple products. Licensable Apple Software and Trademarks include QuickTime, Apple Game Sprockets, OpenGL, Open Transport, the Mac OS Logo, the FireWire Trademark and Built for MacOS X Logo, and others. Software Licensing Agreements in Adobe Acrobat format." Again, Aqua is not listed as a licensable software. Aqua is part of Mac OS X, therefore the license terms for Mac OS X apply to Aqua: http://store.apple.com/Catalog/US/Images/MacOSX.htm Mac OS X is an operating system which allows to run software developed by anybody on any platform. It even ships with development tools - but that's not even relevant. In the Swiss jurisdiction, this is enough to allow us to write software for Mac OS X which uses an Aqua interface. We may freely use other platforms to develop a software with an Aqua interface for Mac OS X. It is definitely not enough to allow us to use the Aqua interface on other platforms since there is no expressed permission by Apple. Of course, I am not a lawyer, especially none who knows the legal implications of this in other countries than Switzerland. But for me, in my country, it would be fine to integrate Quaqua into OpenJDK as long as I ensure that end users can't use it on other platforms. :) -Werner On 02.12.2007, at 20:20, Landon Fuller wrote: > > On Dec 2, 2007, at 5:52 AM, Werner Randelshofer wrote: > >> Except for having to restrict end user usage of the Aqua interface >> to Mac OS X, there appear to be no other limitations imposed by >> Apple Inc. which are legally binding. (At least not in my >> jurisdiction which is Switzerland). >> After all, there is a Windows Look and Feel in OpenJDK with no more >> limitations than this. But maybe Sun entered a special license >> agreement with Microsoft for this. (?) > > Hi Werner -- > > Google's drawing a blank -- do you know where I can find the license > terms for Apple's Aqua artwork? > > Thanks! > Landon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20071202/30718d1d/attachment.html From dalibor.topic at googlemail.com Sun Dec 2 14:07:06 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Sun, 2 Dec 2007 23:07:06 +0100 Subject: Fwd: Feasibility of integrating an Aqua interface In-Reply-To: <985bee770712021307xc0f1bach1d78fa9ce8853e76@mail.gmail.com> References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> <985bee770712021307xc0f1bach1d78fa9ce8853e76@mail.gmail.com> Message-ID: <985bee770712021407u4cf3dc3cx4415ef80cc203b1f@mail.gmail.com> Forwarding here, too. ---------- Forwarded message ---------- From: Dalibor Topic Date: Dec 2, 2007 10:07 PM Subject: Re: Feasibility of integrating an Aqua interface To: Werner Randelshofer On Dec 2, 2007 2:52 PM, Werner Randelshofer wrote: > Dear readers, > I am seeking advice for the feasibility of integrating an Aqua > interface into OpenJDK. Hallo Werner, > Are there any legal limitations which could prevent an integration of > an Aqua interface into OpenJDK? OpenJDK is licensed under the GPLv2 + Assembly exception with some components licensed under GPLv2 + Classpath exception, so code going into its code base needs to be licensed under a GPLv2-compatible license, at least, or needs to be explicitly covered by the Assembly exception, or needs to be covered by the SCA. The third option is the one that is ultimately preferrable over the other ones. > Except for having to restrict end user usage of the Aqua interface to > Mac OS X, there appear to be no other limitations imposed by Apple > Inc. which are legally binding. (At least not in my jurisdiction which > is Switzerland). That may be a problem, as the GPLv2 does not allow further restrictions on usage of the code beyond those in the GPLv2. > Would it be desirable to include the source code of the Quaqua look > and feel into OpenJDK? If you can persuade all authors of the code/artwork/included libraries to sign the SCA, including Apple, then I don't see a problem from a legal point of view. I don't know how easy it will be to get Apple to share the copyright on that artwork, for example, so I'd suggest pursuing the strategy to use Quaqua as a third-party dependency for now, while working behind the scenes to get everyone's consent. There is no harm in asking politely. If Apple says no, then at least we'd be able to work on workarounds for the encumbrancies with Apple's artwork. > After reading Dalibor's advice, I think it might be sensible to > include Quaqua only as an external build dependency into SoyLatte? I think that'd be a good start. If Apple agrees to license its artwork more liberally after being asked politely, we could revisit the discussion, and if they deny, then having it as an external build dependency does not hurt anyone, and should work equally well. For the purpose of making it easy for users eventually using SoyLatte via MacPorts, Fink, etc. I'd suggest packaging Quaqua for one of those distributions, in case it's not packaged yet. As far as binaries go, that aren't hosted on the OpenJDK site, I think it's up to the porting project how it deals with bundling dependencies, if it needs to. Regarding code hosted on the OpenJDK site, the rules need to be more strict, obviously, and that's where discussion on this list comes in, to help us find out what they should be in a specific case. cheers, dalibor topic From werner.randelshofer at bluewin.ch Sun Dec 2 22:36:59 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Mon, 3 Dec 2007 07:36:59 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <985bee770712021407u4cf3dc3cx4415ef80cc203b1f@mail.gmail.com> References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> <985bee770712021307xc0f1bach1d78fa9ce8853e76@mail.gmail.com> <985bee770712021407u4cf3dc3cx4415ef80cc203b1f@mail.gmail.com> Message-ID: <1A8A7705-2FCA-4DC0-B6B1-9A6D4E00A43A@bluewin.ch> Dear Dalibor, On 02.12.2007, at 23:07, Dalibor Topic wrote: > OpenJDK is licensed under the GPLv2 + Assembly exception with some > components > licensed under GPLv2 + Classpath exception, so code going into its > code base needs > to be licensed under a GPLv2-compatible license, at least, or needs to > be explicitly > covered by the Assembly exception, or needs to be covered by the SCA. > > The third option is the one that is ultimately preferrable over the > other ones. Thanks, I knew about the Classpath exception, but I wasn't aware of the Assembly exception and about the alternative possibility using the SCA. >> Except for having to restrict end user usage of the Aqua interface to >> Mac OS X, ? > > That may be a problem, as the GPLv2 does not allow further > restrictions on > usage of the code beyond those in the GPLv2. Yes, you are right. >> Would it be desirable to include the source code of the Quaqua look >> and feel into OpenJDK? > > If you can persuade all authors of the code/artwork/included > libraries to > sign the SCA, including Apple, then I don't see a problem from a legal > point of view. > > I don't know how easy it will be to get Apple to share the copyright > on that artwork, for example, so I'd suggest pursuing the strategy to > use Quaqua as a third-party dependency for now, while working behind > the scenes to get everyone's consent. There is no harm in asking > politely. > If Apple says no, then at least we'd be able to work on workarounds > for > the encumbrancies with Apple's artwork. ? The problem with Quaqua is, that - by design - it can fully implement the Aqua Interface on any platform it is running on. There are many restrictions in its current implementation, but I am about to lift some of them in the process to make it work with SoyLatte on X11. Once this is done, it won't be too hard for others to lift the remaining restrictions. I don't see Apple licensing the full Aqua User Interface under GPLv2. No matter how nicely we ask. ;) I think we can stay within all these legal restrictions by using an approach which does not require inclusion of copyrighted material from Apple into OpenJDK. For example, an OpenJDK AquaLookAndFeel could make use the Cocoa API to render the Aqua interface at runtime. I think this is what Apple does with their look and feel implementations anyway. > As far as binaries go, that aren't hosted on the OpenJDK site, I think > it's up to the > porting project how it deals with bundling dependencies, if it needs > to. Regarding code > hosted on the OpenJDK site, the rules need to be more strict, > obviously, and that's > where discussion on this list comes in, to help us find out what they > should be in a > specific case. Yes, I think we can bundle SoyLatte with Quaqua in this way. With best regards, Werner From werner.randelshofer at bluewin.ch Mon Dec 3 09:58:21 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Mon, 3 Dec 2007 18:58:21 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <1A8A7705-2FCA-4DC0-B6B1-9A6D4E00A43A@bluewin.ch> References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> <985bee770712021307xc0f1bach1d78fa9ce8853e76@mail.gmail.com> <985bee770712021407u4cf3dc3cx4415ef80cc203b1f@mail.gmail.com> <1A8A7705-2FCA-4DC0-B6B1-9A6D4E00A43A@bluewin.ch> Message-ID: On 03.12.2007, at 07:36, Werner Randelshofer wrote: > For example, an OpenJDK AquaLookAndFeel could make use the Cocoa API > to render the Aqua interface at runtime. > I think this is what Apple does with their look and feel > implementations anyway. btw. How do the other OpenJDK ports achieve native renderings? Does Windows and KDE have an API which allows to retrieve artwork from the system? I am asking, because I wonder where I would have to look for a similar feature in the Cocoa API. TIA, Werner From Dmitri.Trembovetski at Sun.COM Mon Dec 3 10:03:00 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 03 Dec 2007 10:03:00 -0800 Subject: Feasibility of integrating an Aqua interface In-Reply-To: References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> <985bee770712021307xc0f1bach1d78fa9ce8853e76@mail.gmail.com> <985bee770712021407u4cf3dc3cx4415ef80cc203b1f@mail.gmail.com> <1A8A7705-2FCA-4DC0-B6B1-9A6D4E00A43A@bluewin.ch> Message-ID: <475444D4.9080300@Sun.COM> Werner Randelshofer wrote: > > On 03.12.2007, at 07:36, Werner Randelshofer wrote: >> For example, an OpenJDK AquaLookAndFeel could make use the Cocoa API >> to render the Aqua interface at runtime. >> I think this is what Apple does with their look and feel >> implementations anyway. > > btw. How do the other OpenJDK ports achieve native renderings? > Does Windows and KDE have an API which allows to retrieve artwork from > the system? Yes, both Windows and GTK L&Fs use similar approach: the images rendered by the OS (or the toolkit in case of GTK) to an off-screen image and then used by the L&F code. Take a look at com.sun.java.swing.plaf.XPStyle for example. Thanks, Dmitri > I am asking, because I wonder where I would have to look for a similar > feature in the Cocoa API. > > TIA, > Werner From carfield at carfield.com.hk Mon Dec 3 10:51:16 2007 From: carfield at carfield.com.hk (Carfield Yim) Date: Tue, 04 Dec 2007 02:51:16 +0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? Message-ID: Look like it is not possible to tell eclipse use SoyLatte using -vm parameter , so I try to start eclipse in command line using following command: ./soylatte16-i386-r2/bin/java -Djava.library.path=plugins/org.eclipse.swt.carbon.macosx_3.3.0.v3346/:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606 -cp eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 -clean -debug --launcher.library plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606/eclipse_1017a.so -startup plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar -vm ./soylatte16-i386-r2/bin/java -keyring ./.eclipse_keyring -consoleLog -showlocation However, may be I still miss some library at -Djava.library.path, I still get following exception, will anyone have idea of fixing this?: !SESSION 2007-12-04 02:39:47.124 ----------------------------------------------- eclipse.buildId=I20070625-1500 java.version=1.6.0_03-p3 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=macosx, ARCH=x86, WS=carbon, NL=zh_HK Framework arguments: -keyring ./.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws carbon -arch x86 -clean -debug -keyring ./.eclipse_keyring -consoleLog -showlocation !ENTRY org.eclipse.osgi 4 0 2007-12-04 02:39:48.176 !MESSAGE Bundle net.sourceforge.eos at 1:start not found. Time to load bundles: 219 !ENTRY org.eclipse.osgi 2 0 2007-12-04 02:39:52.501 !MESSAGE One or more bundles are not resolved because the following root constraints are not resolved: !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.502 !MESSAGE Bundle update at plugins/org.polarion.team.svn.mylyn_1.0.8.jar was not resolved. !SUBENTRY 2 org.polarion.team.svn.mylyn 2 0 2007-12-04 02:39:52.502 !MESSAGE Missing required bundle org.eclipse.mylyn.team.ui_2.0.0.v20070623-1130. !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.503 !MESSAGE Bundle update at plugins/org.mozilla.xulrunner.carbon.macosx_1.8.1.3-20070404/ was not resolved. !SUBENTRY 2 org.mozilla.xulrunner.carbon.macosx 2 0 2007-12-04 02:39:52.503 !MESSAGE Missing required bundle org.eclipse.atf.mozilla.ide.core_0.0.0. !ENTRY org.eclipse.osgi 2 0 2007-12-04 02:39:52.505 !MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists: !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.506 !MESSAGE Bundle update at plugins/org.mozilla.xulrunner.carbon.macosx_1.8.1.3-20070404/ [230] was not resolved. !SUBENTRY 2 org.mozilla.xulrunner.carbon.macosx 2 0 2007-12-04 02:39:52.506 !MESSAGE Missing required bundle org.eclipse.atf.mozilla.ide.core_0.0.0. !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.507 !MESSAGE Bundle update at plugins/org.polarion.team.svn.mylyn_1.0.8.jar [238] was not resolved. !SUBENTRY 2 org.polarion.team.svn.mylyn 2 0 2007-12-04 02:39:52.507 !MESSAGE Missing required bundle org.eclipse.mylyn.team.ui_2.0.0.v20070623-1130. Starting application: 5407 !ENTRY org.eclipse.osgi 4 0 2007-12-04 02:39:52.682 !MESSAGE Application error !STACK 1 java.lang.UnsatisfiedLinkError: no swt-carbon-3346 or swt-carbon in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:219) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.(C.java:21) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:943) at org.eclipse.swt.widgets.Display.create(Display.java:937) at org.eclipse.swt.graphics.Device.(Device.java:119) at org.eclipse.swt.widgets.Display.(Display.java:749) at org.eclipse.swt.widgets.Display.(Display.java:740) at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:498) at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161) at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:133) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:86) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169) at org.eclipse.equinox.launcher.Main.main(Main.java:1144) !ENTRY org.eclipse.osgi 2 0 2007-12-04 02:39:52.698 !MESSAGE One or more bundles are not resolved because the following root constraints are not resolved: !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.699 !MESSAGE Bundle update at plugins/org.polarion.team.svn.mylyn_1.0.8.jar was not resolved. !SUBENTRY 2 org.polarion.team.svn.mylyn 2 0 2007-12-04 02:39:52.699 !MESSAGE Missing required bundle org.eclipse.mylyn.team.ui_2.0.0.v20070623-1130. !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.701 !MESSAGE Bundle update at plugins/org.mozilla.xulrunner.carbon.macosx_1.8.1.3-20070404/ was not resolved. !SUBENTRY 2 org.mozilla.xulrunner.carbon.macosx 2 0 2007-12-04 02:39:52.701 !MESSAGE Missing required bundle org.eclipse.atf.mozilla.ide.core_0.0.0. !ENTRY org.eclipse.osgi 2 0 2007-12-04 02:39:52.704 !MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists: !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.704 !MESSAGE Bundle update at plugins/org.mozilla.xulrunner.carbon.macosx_1.8.1.3-20070404/ [230] was not resolved. !SUBENTRY 2 org.mozilla.xulrunner.carbon.macosx 2 0 2007-12-04 02:39:52.705 !MESSAGE Missing required bundle org.eclipse.atf.mozilla.ide.core_0.0.0. !SUBENTRY 1 org.eclipse.osgi 2 0 2007-12-04 02:39:52.706 !MESSAGE Bundle update at plugins/org.polarion.team.svn.mylyn_1.0.8.jar [238] was not resolved. !SUBENTRY 2 org.polarion.team.svn.mylyn 2 0 2007-12-04 02:39:52.706 !MESSAGE Missing required bundle org.eclipse.mylyn.team.ui_2.0.0.v20070623-1130. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From landonf at bikemonkey.org Mon Dec 3 11:47:04 2007 From: landonf at bikemonkey.org (Landon Fuller) Date: Mon, 3 Dec 2007 11:47:04 -0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: References: Message-ID: On Dec 3, 2007, at 10:51, Carfield Yim wrote: > Look like it is not possible to tell eclipse use SoyLatte using -vm > parameter , so I try to start eclipse in command line using > following command: > > ./soylatte16-i386-r2/bin/java -Djava.library.path=plugins/ > org.eclipse.swt.carbon.macosx_3.3.0.v3346/:plugins/ > org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606 -cp > eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar > org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 - > clean -debug --launcher.library plugins/ > org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606/ > eclipse_1017a.so -startup plugins/ > org.eclipse.equinox.launcher_1.0.0.v20070606.jar -vm ./soylatte16- > i386-r2/bin/java -keyring ./.eclipse_keyring -consoleLog -showlocation > > However, may be I still miss some library at -Djava.library.path, I > still get following exception, will anyone have idea of fixing this?: My two minute solution (just now) was to drop the SWT JNI libraries in the java.library.path manually. Eclipse seems to be running fine. I couldn't find the original SWT binaries in the eclipse installation tree -- does eclipse extract them from a jar? Also, SoyLatte R2 only supports shared libraries with the standard .dylib extension. R3 added a fall-back to Apple's .jnilib. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20071203/a6b45250/attachment.bin From puybaret at eteks.com Mon Dec 3 12:14:06 2007 From: puybaret at eteks.com (Emmanuel Puybaret) Date: Mon, 03 Dec 2007 21:14:06 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> Message-ID: Hi, Could you explain what SCA means ? @Werner Randelshofer: > Are there any legal limitations which could prevent an integration of > an Aqua interface into OpenJDK? > Except for having to restrict end user usage of the Aqua interface to > Mac OS X, there appear to be no other limitations imposed by Apple > Inc. which are legally binding. (At least not in my jurisdiction which > is Switzerland). > > After all, there is a Windows Look and Feel in OpenJDK with no more > limitations than this. But maybe Sun entered a special license > agreement with Microsoft for this. (?) You should ask them, but I would bet that their lock based on System.getProperty("os.name") in WindowsLookAndFeel is actually just there to avoid legal problems. > Would it be desirable to include the source code of the Quaqua look > and feel into OpenJDK? > Quaqua contains a substantial number of artwork copyrighted by Apple, > Inc. This is no problem in my jurisdiction, but it might be for other > jurisdictions. I would propose to integrate to OpenJDK a version of Quaqua look and feel with the same lock used in WindowsLookAndFeel. If some people disable this lock, it's their problem not yours ! I would try also to contact Apple legal team. Maybe Apple Java team will be able to give some advice. BTW, I started the implementation of an AWT Toolkit based on SWT. I succeeded to display an AWT Frame with AWT Buttons. At this time, it didn't look so difficult but as always, the first programming lines are not the most difficult ones. ;-) Best regards -- Emmanuel PUYBARET Email : puybaret at eteks.com Web : http://www.eteks.com From dalibor.topic at googlemail.com Mon Dec 3 12:21:30 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Mon, 3 Dec 2007 21:21:30 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: References: <06A14BEA-82B8-4A1E-B84C-1DCD652FF520@bluewin.ch> Message-ID: <985bee770712031221p4fb94a3cgb29fa1cd4c180eb0@mail.gmail.com> On Dec 3, 2007 9:14 PM, Emmanuel Puybaret wrote: > Hi, > > Could you explain what SCA means ? Sure. It's the Sun Contributor Agreement. It's a legal prerequisite for getting patches into OpenJDK. See Section 0 of http://openjdk.java.net/contribute/ and the FAQ at http://www.sun.com/software/opensource/contributor_agreement.jsp for more detailed information on it. cheers, dalibor topic From lnelson at llnl.gov Mon Dec 3 13:51:00 2007 From: lnelson at llnl.gov (Leif Nelson) Date: Mon, 03 Dec 2007 14:51:00 -0700 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: References: Message-ID: <47547A44.6080401@llnl.gov> For eclipse 3.3.1, the swt .jnilib's seem to be hiding in the plugins/org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar file. I did the following to startup eclipse 3.3.1 on my mac: /apps/eclipse-3.3.1 $ cd plugins/ /apps/eclipse-3.3.1/plugins $ mkdir swt-carbon-macosx /apps/eclipse-3.3.1/plugins $ cd swt-carbon-macosx/ /apps/eclipse-3.3.1/plugins/swt-carbon-macosx $ jar -xf ../org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar /apps/eclipse-3.3.1/plugins/swt-carbon-macosx $ cd ../.. /apps/eclipse-3.3.1 $ /opt/soylatte16-i386-r3/bin/java -Xmx1024m -XX:MaxPermSize=128m -Djava.library.path=plugins/swt-carbon-macosx:plugins/org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019 -cp plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 -clean -debug --launcher.library plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019/eclipse_1021.so -startup plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar -vm /opt/soylatte16-i386-r3/bin/java -keyring ./.eclipse_keyring -consoleLog -showlocation Eclipse then popped right up! --Leif Landon Fuller wrote: > > On Dec 3, 2007, at 10:51, Carfield Yim wrote: > >> Look like it is not possible to tell eclipse use SoyLatte using -vm >> parameter , so I try to start eclipse in command line using following >> command: >> >> ./soylatte16-i386-r2/bin/java >> -Djava.library.path=plugins/org.eclipse.swt.carbon.macosx_3.3.0.v3346/:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606 >> -cp eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar >> org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 >> -clean -debug --launcher.library >> plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606/eclipse_1017a.so >> -startup plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar >> -vm ./soylatte16-i386-r2/bin/java -keyring ./.eclipse_keyring >> -consoleLog -showlocation >> >> However, may be I still miss some library at -Djava.library.path, I >> still get following exception, will anyone have idea of fixing this?: > > My two minute solution (just now) was to drop the SWT JNI libraries in > the java.library.path manually. Eclipse seems to be running fine. > I couldn't find the original SWT binaries in the eclipse installation > tree -- does eclipse extract them from a jar? > > Also, SoyLatte R2 only supports shared libraries with the standard > .dylib extension. R3 added a fall-back to Apple's .jnilib. > > -landonf From werner.randelshofer at bluewin.ch Tue Dec 4 10:10:02 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Tue, 4 Dec 2007 19:10:02 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: References: Message-ID: <99BCD5F9-5F66-4FFB-B25E-EC12066F2545@bluewin.ch> Dear Emmanuel, On 03.12.2007, at 21:14, Emmanuel Puybaret wrote: > I would propose to integrate to OpenJDK a version of Quaqua look and > feel > with the same lock used in WindowsLookAndFeel. If some people > disable this > lock, it's their problem not yours ! I would like to integrate it too, but we have to do it on a solid legal basis. > I would try also to contact Apple legal team. Maybe Apple Java team > will be > able to give some advice. Maybe we don't need to integrate copyrighted artwork into OpenJDK at all. Thanks to Dmitri's pointer and some great help by an off list reply, we might be able to substantially reduce the amount of artwork needed in the source code: It turns out, that Apple ported the Carbon HITheme API to 64 bit. Using this API one can render elements of Aqua components. On my computer the HITheme.h file is located in the directory /Developers/SDKs/MacOSX10.5.skd/System/Library/Frameworks/ Carbon.framework/Versions/A/Frameworks/HIToolbos.framework/Versions/A/ Headers I don't know how far this API will get us. But it is sure worth a try. > BTW, I started the implementation of an AWT Toolkit based on SWT. > I succeeded to display an AWT Frame with AWT Buttons. At this time, it > didn't look so difficult but as always, the first programming lines > are not > the most difficult ones. ;-) That's great. I am looking forward to see the first working AWT Frame with Buttons in SoyLatte. :) With best regards, Werner From psccox at gmail.com Tue Dec 4 11:48:04 2007 From: psccox at gmail.com (Peter Cox) Date: Wed, 5 Dec 2007 06:48:04 +1100 Subject: Intro Message-ID: <7d4375bd0712041148r5f616ae3o314b077121b23ef2@mail.gmail.com> G'day, I'm a long term Java developer. The ports being interested in seeing would be to (a) OS X. We're deploying to 1.5 at work with a bunch of swinglabs code that's since been rolled into 1.6 - (GroupLayout/SwingWorker etc). It's doubtful we'd deploy to 1.6 overnight even if Apple released Java soon due to the requirement to upgrade the OS too. What help I can bring to the table I'm not sure given I don't own a Mac but... The other 2 are pipe-dreams, purely from a user perspective. (b) maemo. My Nokia 770 is barely 12 months old but has already been superseded twice! (c) Haiku. As I hinted to Dalibor on javalobby, I'd be tempted to dump unix if there were a working JRE. Pete. From psccox at gmail.com Tue Dec 4 11:57:03 2007 From: psccox at gmail.com (Peter Cox) Date: Wed, 5 Dec 2007 06:57:03 +1100 Subject: Feasibility of integrating an Aqua interface Message-ID: <7d4375bd0712041157m624e4613y7ac0c964d1c596da@mail.gmail.com> One might consider what other look and feels have done and integrate the proprietary resources via a theme. The fall-back position could be then to supply a basic theme sourcing icons and the like from GPL friendly sources. If there are dependencies to specific OS X revisions, one might have a tiger theme, leopard theme etc. From werner.randelshofer at bluewin.ch Tue Dec 4 13:03:21 2007 From: werner.randelshofer at bluewin.ch (Werner Randelshofer) Date: Tue, 4 Dec 2007 22:03:21 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <7d4375bd0712041157m624e4613y7ac0c964d1c596da@mail.gmail.com> References: <7d4375bd0712041157m624e4613y7ac0c964d1c596da@mail.gmail.com> Message-ID: <95B96D54-794A-4340-BA26-8F686563E990@bluewin.ch> Dear Peter, I also thought about this, but I am reluctant to doing it. I think that this wouldn't solve any licensing problems. We would still end up with one part of the code being in OpenJDK, and the other part being in a separate project under a different license. I think we would get maintenance problems. There is a tight coupling between the look and the feel. To get them both right, one would constantly have to coordinate both projects. Lets see if we can make a look and feel with the Mac OSX HITheme API. Maybe we can avoid licensing issues by using this API. With best regards, Werner On 04.12.2007, at 20:57, Peter Cox wrote: > One might consider what other look and feels have done and integrate > the proprietary resources via a theme. > > The fall-back position could be then to supply a basic theme sourcing > icons and the like from GPL friendly sources. > > If there are dependencies to specific OS X revisions, one might have a > tiger theme, leopard theme etc. From volker.simonis at gmail.com Wed Dec 5 01:51:19 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Dec 2007 10:51:19 +0100 Subject: Licence of OpenJDK Ports Message-ID: Hi porters, I have a question regarding the licence under which "official" OpenJDK ports will be available. As far as I understand, all submissions will have to be made under a Sun Contributor Agreement (SCA). This would be necessary to allow SUN to integrate changes from the ports upstream into the SUN JDK which will probably be the goal of most of the OpenJDK ports (in order to facilitate the maintenance of the ports). However this would also allow SUN to sublicence OpenJDK ports under a commercial licence to its licencees, the same way as it does this with the current SUN JDK. Is this true and will SUN do this (possibly upon request of licencees)? I ask this questions for the following reason: suppose a company wants to donate some ports to the OpenJDK projekt, but at the same time still wants to distribute these ports under a commercial licence (much the same way of dual licencing that SUN does with OpenJDK/SUN JDK). For this company, it would be impossible to benefit from further developments and improvments in the OpenJDK port version, if it would not have the possiblity to get these OpenJDK port sources back from SUN under a commercial licence. Will this be possible? And will all licencees of SUN have the possibility of getting the sources of an OpenJDK port under a commercial licence, or just the initial submitter? It would be nice, if somebody could clarify this questions. With best regards, Volker From carfield at carfield.com.hk Wed Dec 5 11:35:44 2007 From: carfield at carfield.com.hk (Carfield Yim) Date: Thu, 6 Dec 2007 03:35:44 +0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: <47547A44.6080401@llnl.gov> References: <47547A44.6080401@llnl.gov> Message-ID: I updated to eclipse 3.3.1 and follow existly procedure ( well, with differe path... ) but still getting the exception: java.lang.UnsatisfiedLinkError: no swt-carbon-3347 or swt-carbon in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:219) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.(C.java:21) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:945) at org.eclipse.swt.widgets.Display.create(Display.java:939) at org.eclipse.swt.graphics.Device.(Device.java:119) at org.eclipse.swt.widgets.Display.(Display.java:749) at org.eclipse.swt.widgets.Display.(Display.java:740) at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:498) at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161) at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay( IDEApplication.java:133) at org.eclipse.ui.internal.ide.application.IDEApplication.start( IDEApplication.java:86) at org.eclipse.equinox.internal.app.EclipseAppHandle.run( EclipseAppHandle.java:169) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication( EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start( EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java :363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java :176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447) at org.eclipse.equinox.launcher.Main.run(Main.java:1173) at org.eclipse.equinox.launcher.Main.main(Main.java:1148) Anyone have idea to resolve that? On 12/4/07, Leif Nelson wrote: > > For eclipse 3.3.1, the swt .jnilib's seem to be hiding in the > plugins/org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar file. I did the > following to startup eclipse 3.3.1 on my mac: > > /apps/eclipse-3.3.1 $ cd plugins/ > /apps/eclipse-3.3.1/plugins $ mkdir swt-carbon-macosx > /apps/eclipse-3.3.1/plugins $ cd swt-carbon-macosx/ > /apps/eclipse-3.3.1/plugins/swt-carbon-macosx $ jar -xf > ../org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar > /apps/eclipse-3.3.1/plugins/swt-carbon-macosx $ cd ../.. > /apps/eclipse-3.3.1 $ /opt/soylatte16-i386-r3/bin/java -Xmx1024m > -XX:MaxPermSize=128m > - > Djava.library.path=plugins/swt-carbon-macosx:plugins/org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019 > -cp plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar > org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 -clean > -debug --launcher.library > > plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019/eclipse_1021.so > -startup plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar > -vm /opt/soylatte16-i386-r3/bin/java -keyring ./.eclipse_keyring > -consoleLog -showlocation > > Eclipse then popped right up! > > --Leif > > Landon Fuller wrote: > > > > On Dec 3, 2007, at 10:51, Carfield Yim wrote: > > > >> Look like it is not possible to tell eclipse use SoyLatte using -vm > >> parameter , so I try to start eclipse in command line using following > >> command: > >> > >> ./soylatte16-i386-r2/bin/java > >> - > Djava.library.path=plugins/org.eclipse.swt.carbon.macosx_3.3.0.v3346/:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606 > >> -cp eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar > >> org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 > >> -clean -debug --launcher.library > >> > plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606/eclipse_1017a.so > >> -startup plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar > >> -vm ./soylatte16-i386-r2/bin/java -keyring ./.eclipse_keyring > >> -consoleLog -showlocation > >> > >> However, may be I still miss some library at -Djava.library.path, I > >> still get following exception, will anyone have idea of fixing this?: > > > > My two minute solution (just now) was to drop the SWT JNI libraries in > > the java.library.path manually. Eclipse seems to be running fine. > > I couldn't find the original SWT binaries in the eclipse installation > > tree -- does eclipse extract them from a jar? > > > > Also, SoyLatte R2 only supports shared libraries with the standard > > .dylib extension. R3 added a fall-back to Apple's .jnilib. > > > > -landonf > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20071206/957f7d53/attachment.html From mr at sun.com Wed Dec 5 14:19:17 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 05 Dec 2007 14:19:17 -0800 Subject: Licence of OpenJDK Ports In-Reply-To: volker.simonis@gmail.com; Wed, 05 Dec 2007 10:51:19 +0100; Message-ID: <20071205221917.BA25B2783C7@eggemoggin.niobe.net> > Date: Wed, 05 Dec 2007 10:51:19 +0100 > From: volker.simonis at gmail.com > I have a question regarding the licence under which "official" OpenJDK > ports will be available. ... Good questions! I think I know most of the answers, but not being a lawyer and all I've instead forwarded your query to Carla Schroer of Sun. (She's not a lawyer either, but she talks to them way more often than I do and -- better still -- actually seems to understand what they say.) - Mark From dalibor.topic at googlemail.com Wed Dec 5 22:09:02 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Thu, 6 Dec 2007 07:09:02 +0100 Subject: Licence of OpenJDK Ports In-Reply-To: <20071205221917.BA25B2783C7@eggemoggin.niobe.net> References: <20071205221917.BA25B2783C7@eggemoggin.niobe.net> Message-ID: <985bee770712052209n484475a7xf7fb0865b3e7dc42@mail.gmail.com> On Dec 5, 2007 11:19 PM, Mark Reinhold wrote: > > Date: Wed, 05 Dec 2007 10:51:19 +0100 > > From: volker.simonis at gmail.com > > > I have a question regarding the licence under which "official" OpenJDK > > ports will be available. ... > > Good questions! > > I think I know most of the answers, but not being a lawyer and all > I've instead forwarded your query to Carla Schroer of Sun. (She's > not a lawyer either, but she talks to them way more often than I do > and -- better still -- actually seems to understand what they say.) > A very interesting scenario here is one where JDK licensees among themselves, and their users (SoyLatte + Apple would be great), could use OpenJDK to collaborate with each other on development of ports that they share a mutual interest in, be they chip, operating system, or application server vendors, but have diametrically opposed licensing needs (users requesting free software vs. users requesting non-free software). cheers, dalibor topic From lnelson at llnl.gov Thu Dec 6 08:56:58 2007 From: lnelson at llnl.gov (Leif Nelson) Date: Thu, 06 Dec 2007 09:56:58 -0700 Subject: soylatte and java.net.preferIPv4Stack=true Message-ID: <475829DA.7090000@llnl.gov> Hi all- I've been using soylatte for the last few days to work with the Oracle application server oc4j. I was puzzled by it's extremely slow startup time using soylatte. So, I did some investigation, and found that setting the system property java.net.preferIPv4Stack=true causes calling InetAddress.getLocalHost() to take at least 8 seconds to execute on my Mac Pro. It seems that the oc4j server sets this property in it's main() method on startup, and it is not configurable! Also, each subsequent invocation of InetAddress.getLocalHost() takes another 8 seconds, and apparently this method is called several times! I did some tests on several macs running both Tiger & Leopard with java5 and java6 to demonstrate the issue. After some tracing with -Djava.net.preferIPv4Stack=true, I found that the time is all taken up inside of the native method: java.net.Inet4AddressImpl.getLocalHostName(). If I trace with -Djava.net.preferIPv4Stack=false (the default), I found that the native method java.net.Inet6AddressImpl.getLocalHostName() gets called instead returns very quickly. I hope this narrows it down enough to find out what's wrong. :-) Thanks, --Leif Here's my test class: package test; import java.net.InetAddress; public class TestHostName { public static void main(String[] args) { try { long start = System.currentTimeMillis(); InetAddress addr = InetAddress.getLocalHost(); long stop = System.currentTimeMillis(); System.out.println("Found: " + addr.getHostAddress() + " in: " + (stop - start) + " ms."); } catch (Exception e) { e.printStackTrace(); } } } Here's some results from running the tests. The results are very similar on both Tiger (32 bit) & Leopard (32 & 64 bit) ~/testhost $ uname -a Darwin bridger.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 ~/testhost $ /opt/soylatte16-i386-r3/bin/javac test/TestHostName.java ~/testhost $ /opt/soylatte16-i386-r3/bin/java -Djava.net.preferIPv4Stack=true test.TestHostName Found: 10.10.11.13 in: 8581 ms. ~/testhost $ /opt/soylatte16-i386-r3/bin/java test.TestHostName Found: 10.10.11.13 in: 208 ms. ~/testhost $ /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/bin/javac test/TestHostName.java ~/testhost $ /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/bin/java -Djava.net.preferIPv4Stack=true test.TestHostName Found: 10.10.11.13 in: 41 ms. ~/testhost $ /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/bin/java test.TestHostName Found: 10.10.11.13 in: 3 ms. ~/testhost $ /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home/bin/javac test/TestHostName.java ~/testhost $ /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home/bin/java -Djava.net.preferIPv4Stack=true test.TestHostName Found: 10.10.11.13 in: 8 ms. ~/testhost $ /System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home/bin/java test.TestHostName Found: 10.10.11.13 in: 7 ms. From carfield at carfield.com.hk Thu Dec 6 10:00:47 2007 From: carfield at carfield.com.hk (Carfield Yim) Date: Fri, 7 Dec 2007 02:00:47 +0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: References: Message-ID: > > My two minute solution (just now) was to drop the SWT JNI libraries > in the java.library.path manually. Eclipse seems to be running fine. > I couldn't find the original SWT binaries in the eclipse installation > tree -- does eclipse extract them from a jar? > \ Tried... still fail > > Also, SoyLatte R2 only supports shared libraries with the > standard .dylib extension. R3 added a fall-back to Apple's .jnilib. > May be this is the problem... I can only use the binary distribution because I cannot build it because I am using 10.4 ... may be it only work on 10.5 ?? From Carla.Schroer at Sun.COM Thu Dec 6 09:36:50 2007 From: Carla.Schroer at Sun.COM (Carla.Schroer at Sun.COM) Date: Thu, 06 Dec 2007 09:36:50 -0800 Subject: Licence of OpenJDK Ports In-Reply-To: <20071205221917.BA25B2783C7@eggemoggin.niobe.net> References: <20071205221917.BA25B2783C7@eggemoggin.niobe.net> Message-ID: <47583332.2060706@Sun.COM> Hi folks, I am drafting an answer for this, but I need to run it by legal before posting. Our general counsel for Java is out on vacation, as of today until Dec 17. I will try to get a different lawyer to take a look, but I can't really claim this is an urgent item, so please give me a little time on this one. Sorry for the delay! Carla Mark Reinhold wrote: >> Date: Wed, 05 Dec 2007 10:51:19 +0100 >> From: volker.simonis at gmail.com >> > > >> I have a question regarding the licence under which "official" OpenJDK >> ports will be available. ... >> > > Good questions! > > I think I know most of the answers, but not being a lawyer and all > I've instead forwarded your query to Carla Schroer of Sun. (She's > not a lawyer either, but she talks to them way more often than I do > and -- better still -- actually seems to understand what they say.) > > - Mark > From lnelson at llnl.gov Thu Dec 6 11:16:15 2007 From: lnelson at llnl.gov (Leif Nelson) Date: Thu, 06 Dec 2007 12:16:15 -0700 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: References: Message-ID: <47584A7F.8080105@llnl.gov> The steps I outlined previously were performed on a 10.4 mac... Did you try it with soylatte-r3 yet, because I believe it will not work with r2 due to the .dylib/.jnilib fallback issue. --Leif Carfield Yim wrote: >> My two minute solution (just now) was to drop the SWT JNI libraries >> in the java.library.path manually. Eclipse seems to be running fine. >> I couldn't find the original SWT binaries in the eclipse installation >> tree -- does eclipse extract them from a jar? >> \ >> > > Tried... still fail > > >> Also, SoyLatte R2 only supports shared libraries with the >> standard .dylib extension. R3 added a fall-back to Apple's .jnilib. >> >> > May be this is the problem... I can only use the binary distribution > because I cannot build it because I am using 10.4 ... may be it only > work on 10.5 ?? > > From bryanv at haiku-os.org Fri Dec 7 11:21:07 2007 From: bryanv at haiku-os.org (Bryan Varner) Date: Fri, 7 Dec 2007 14:21:07 -0500 (EST) Subject: Proposal: Haiku port of OpenJDK Message-ID: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> Greetings, My name is Bryan Varner, and I am a developer at the Haiku Project (www.haiku-os.org). I am also the lead of our newly created Java Team, an initiative to bring first-class support for Java technologies to the Haiku operating system. I am writing to you because we would like to start by producing an OpenJDK port for Haiku, under the guidance and supervision of this group. Consider this our proposal for your review and approval. # The team Our team is currently comprised of several Haiku developers, including a couple of 'veterans,' that will be assisting the effort in various areas from within Haiku. At least two of the members, Andrew Bachmann and I, were actually involved in the port of JDK 1.4.2 to the BeOS, which Haiku is compatible with (source and binary!). All members of our team who wish to participate in OpenJDK development and not just Haiku development (we expect to have to add things to Haiku in order to support the OpenJDK port) will abide by and fully participate with OpenJDK and their house rules. # Past achievements The results of our Java port to BeOS were never released (mainly to the demise of BeOS), but nevertheless included the following achievements: * Bootstrapping the 1.4.2 build using jikes and a javah replacement written in C++. * A working, native AWT that uses the BeAPI. Most of Java2D is implemented. I dare you to find a cleaner AWT implementation! * Ability to run SwingSet, Java2D demos, JBoss, Tomcat, etc. * 1:1 BeOS native threading model -- which isn't pthreads. # Goals of the project Our ultimate goal is to have a JCK compliant JDK for Haiku that could be merged upstream. Initially, our port will focus on support for the x86 processor line. Haiku has the (long-term) intention to support additional architectures. As these are added to Haiku, our intent would be to add support to these in the OpenJDK as well. A consistent user experience across architectures with Haiku is important to us. In an ideal world, our port will be ready in time for the Java 7 release. We will do what we can to make that a reality. Yesterday, Dec. 6, 2007, we held an internal IRC meeting with the core Haiku developers to discuss this initiative. As part of that meeting, we had the opportunity to converse with Dalibor Topic (whom we invited to join us), and whom I'm sure you all know. Dalibor gave the Haiku developers in attendance a good overview of how the project works, and we now have a better understanding of the project organization, the importance of the SCA. We are ready to commit to abide by the rules at all times. Speaking for the Haiku Java team, I respectfully ask that you consider our proposal to port OpenJDK to Haiku. If you have any questions, be they technical, organizational, or otherwise, feel free to direct them my way. We eagerly await your response. Bryan Varner Java Team Lead Haiku Project (http://www.haiku-os.org) From puybaret at eteks.com Fri Dec 7 11:33:50 2007 From: puybaret at eteks.com (Emmanuel Puybaret) Date: Fri, 07 Dec 2007 20:33:50 +0100 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: Message-ID: >> My two minute solution (just now) was to drop the SWT JNI libraries >> in the java.library.path manually. Eclipse seems to be running fine. >> I couldn't find the original SWT binaries in the eclipse installation >> tree -- does eclipse extract them from a jar? >> \ > > Tried... still fail It looks like SWT DLLs are suffixed by .jnilib and SoyLatte wants DLLs that are suffixed by .dylib. So I succeeded to make run SWT (but I didn't try Eclipse yet) by downloading SWT binaries from http://www.eclipse.org/swt/, renaming the .jnilib files to .dylib in swt.jar, and simply include swt.jar in classpath :-) BTW, the AWT port based upon SWT is going well : I've got most AWT components and AWT handlers running. The big part that's still missing is Canvas and Graphics. Best regards -- Emmanuel PUYBARET Email : puybaret at eteks.com Web : http://www.eteks.com From dalibor.topic at googlemail.com Fri Dec 7 12:23:54 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Fri, 7 Dec 2007 21:23:54 +0100 Subject: Proposal: Haiku port of OpenJDK In-Reply-To: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> References: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> Message-ID: <985bee770712071223g2a93c21i23f3944ddc6847ea@mail.gmail.com> Thank you very much for the proposal, Bryan. Since your proposal is the first one, I am trying a bit to write up procedures for the porters group as we go. I invite the porters group Members to review, discuss and help improve your proposal. If, after discussion, the proposal finds a Member willing to support the proposal, the Member should then submit the project proposal to the OpenJDK project's announce and discuss mailing lists per http://openjdk.java.net/projects/ . The further approval process would follow the rules outlined in that document. cheers, dalibor topic From linuxhippy at gmail.com Fri Dec 7 15:52:23 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 8 Dec 2007 00:52:23 +0100 Subject: Proposal: Haiku port of OpenJDK In-Reply-To: <985bee770712071223g2a93c21i23f3944ddc6847ea@mail.gmail.com> References: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> <985bee770712071223g2a93c21i23f3944ddc6847ea@mail.gmail.com> Message-ID: <194f62550712071552x313eddaaj485e9da8fbeeae58@mail.gmail.com> > My name is Bryan Varner, and I am a developer at the Haiku Project > (www.haiku-os.org). I am also the lead of our newly created Java Team, an > initiative to bring first-class support for Java technologies to the Haiku > operating system. I am writing to you because we would like to start by > producing an OpenJDK port for Haiku, under the guidance and supervision of > this group. Consider this our proposal for your review and approval. I know this is quite off-topic so sorry for flooding the list with useless traffic ... but its really refreshing to see activity on the porting side. Haiku is a great OS, and I guess it would really benefit from a good java-implementation - the same way Java would benefit because it would become available on many OSs with no strong market force behind it. Conclusion: Just happy to see something happen. Good luck for the port :) lg Clemens From carfield at carfield.com.hk Fri Dec 7 22:50:22 2007 From: carfield at carfield.com.hk (Carfield Yim) Date: Sat, 8 Dec 2007 14:50:22 +0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: <47584A7F.8080105@llnl.gov> References: <47584A7F.8080105@llnl.gov> Message-ID: Thanks, eclipse can start with latest binary. However there are few exceptions and it crash after a while. I've email the corresponding stack trace and dump file to you at separate email On Dec 7, 2007 3:16 AM, Leif Nelson wrote: > The steps I outlined previously were performed on a 10.4 mac... Did you > try it with soylatte-r3 yet, because I believe it will not work with r2 > due to the .dylib/.jnilib fallback issue. > > --Leif > > > Carfield Yim wrote: > >> My two minute solution (just now) was to drop the SWT JNI libraries > >> in the java.library.path manually. Eclipse seems to be running fine. > >> I couldn't find the original SWT binaries in the eclipse installation > >> tree -- does eclipse extract them from a jar? > >> \ > >> > > > > Tried... still fail > > > > > >> Also, SoyLatte R2 only supports shared libraries with the > >> standard .dylib extension. R3 added a fall-back to Apple's .jnilib. > >> > >> > > May be this is the problem... I can only use the binary distribution > > because I cannot build it because I am using 10.4 ... may be it only > > work on 10.5 ?? > > > > > From landonf at bikemonkey.org Sat Dec 8 12:47:15 2007 From: landonf at bikemonkey.org (Landon Fuller) Date: Sat, 8 Dec 2007 12:47:15 -0800 Subject: soylatte and java.net.preferIPv4Stack=true In-Reply-To: <475829DA.7090000@llnl.gov> References: <475829DA.7090000@llnl.gov> Message-ID: <74534C17-916C-4F2D-8D17-0CA5CA2BABBA@bikemonkey.org> On Dec 6, 2007, at 8:56 AM, Leif Nelson wrote: > Also, each subsequent invocation of InetAddress.getLocalHost() > takes another 8 seconds, and apparently this method is called > several times! I did some tests on several macs running both Tiger > & Leopard with java5 and java6 to demonstrate the issue. > After some tracing with -Djava.net.preferIPv4Stack=true, I found > that the time is all taken up inside of the native method: > java.net.Inet4AddressImpl.getLocalHostName(). > > If I trace with -Djava.net.preferIPv4Stack=false (the default), I > found that the native method > java.net.Inet6AddressImpl.getLocalHostName() gets called instead > returns very quickly. > > I hope this narrows it down enough to find out what's wrong. :-) Thanks! I tracked it down to this copy/paste bug in the BSD-specific code (which I believe I wrote some time ago, so it's my bug) error = getaddrinfo(hostname, "domain", &hints, &res); The "domain" service argument causes getaddrinfo() on Mac OS X to make (time consuming) MDNS SRV requests for the service: 12:16:03.619145 IP 10.0.50.246.mdns > 224.0.0.251.mdns: 0 SRV (QM)? _domain._udp.max.local. (40) The service argument should have been NULL. I committed a fix for this upstream, and will include it in the next release: landonf at max:/tmp> /tmp/j-build/bsd-i586/bin/java - Djava.net.preferIPv4Stack=true TestHostName Found: 10.0.50.246 in: 9 ms. Patch: http://hg.bikemonkey.org/javasrc_1_6_jrl_darwin_stable/rev/219cd1380f35 Thanks again for the report, -landonf From landonf at bikemonkey.org Sat Dec 8 17:19:59 2007 From: landonf at bikemonkey.org (Landon Fuller) Date: Sat, 8 Dec 2007 17:19:59 -0800 Subject: Feasibility of integrating an Aqua interface In-Reply-To: References: Message-ID: <49198660-608F-4BBF-9586-80585019F276@bikemonkey.org> On Dec 3, 2007, at 12:14 PM, Emmanuel Puybaret wrote: > BTW, I started the implementation of an AWT Toolkit based on SWT. > I succeeded to display an AWT Frame with AWT Buttons. At this time, it > didn't look so difficult but as always, the first programming lines > are not > the most difficult ones. ;-) Heya Emmanuel -- Is your code available publicly? Cheers, Landon From puybaret at eteks.com Sat Dec 8 18:10:58 2007 From: puybaret at eteks.com (Emmanuel Puybaret) Date: Sun, 09 Dec 2007 03:10:58 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <49198660-608F-4BBF-9586-80585019F276@bikemonkey.org> Message-ID: >> BTW, I started the implementation of an AWT Toolkit based on SWT. >> I succeeded to display an AWT Frame with AWT Buttons. At this time, it >> didn't look so difficult but as always, the first programming lines >> are not the most difficult ones. ;-) > > Is your code available publicly? As I get very close to a toolkit that can work correctly with most features (I implemented almost all AWT peers classes already), I prefer to go on a little further before anything public. At this time, I plan to put it on my website under GNU GPL license, but I'm opened to any idea about the best place and the best license. One thing that is nice for you porters, is that this toolkit may be useful to get Java 6 or 7 on other platforms where SWT is available. BTW, I noticed that System.getProperty("os.name") returns "Darwin" and not "Mac OS X" in SoyLatte. It's not a very good idea if people want to port their program to SoyLatte. Let's keep in touch ! Cheers -- Emmanuel PUYBARET Email : puybaret at eteks.com Web : http://www.eteks.com From klssrfr at cox.net Sat Dec 8 22:05:45 2007 From: klssrfr at cox.net (Jeff Payne) Date: Sat, 8 Dec 2007 22:05:45 -0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? Message-ID: <2D7753EB-9AC4-438F-9005-61BF081C8962@cox.net> Hi all, Are there directions to run eclipse under SoyLatte? It would really be helpful. :) Jeff From carfield at carfield.com.hk Sat Dec 8 22:39:08 2007 From: carfield at carfield.com.hk (Carfield Yim) Date: Sun, 9 Dec 2007 14:39:08 +0800 Subject: Possible to use mac os x JDK 1.6 port ( SoyLatte ) to launch eclipse? In-Reply-To: <2D7753EB-9AC4-438F-9005-61BF081C8962@cox.net> References: <2D7753EB-9AC4-438F-9005-61BF081C8962@cox.net> Message-ID: This post is work On 12/4/07, Leif Nelson wrote: > > For eclipse 3.3.1, the swt .jnilib's seem to be hiding in the > plugins/org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar file. I did the > following to startup eclipse 3.3.1 on my mac: > > /apps/eclipse-3.3.1 $ cd plugins/ > /apps/eclipse-3.3.1/plugins $ mkdir swt-carbon-macosx > /apps/eclipse-3.3.1/plugins $ cd swt-carbon-macosx/ > /apps/eclipse-3.3.1/plugins/swt-carbon-macosx $ jar -xf > ../org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar > /apps/eclipse-3.3.1/plugins/swt-carbon-macosx $ cd ../.. > /apps/eclipse-3.3.1 $ /opt/soylatte16-i386-r3/bin/java -Xmx1024m > -XX:MaxPermSize=128m > - > Djava.library.path=plugins/swt-carbon-macosx:plugins/org.eclipse.swt.carbon.macosx_3.3.2.v3347a.jar:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019 > -cp plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar > org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 -clean > -debug --launcher.library > > plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.2.R331_v20071019/eclipse_1021.so > -startup plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar > -vm /opt/soylatte16-i386-r3/bin/java -keyring ./.eclipse_keyring > -consoleLog -showlocation > > Eclipse then popped right up! > > --Leif > > Landon Fuller wrote: > > > > On Dec 3, 2007, at 10:51, Carfield Yim wrote: > > > >> Look like it is not possible to tell eclipse use SoyLatte using -vm > >> parameter , so I try to start eclipse in command line using following > >> command: > >> > >> ./soylatte16-i386-r2/bin/java > >> - > Djava.library.path=plugins/org.eclipse.swt.carbon.macosx_3.3.0.v3346/:plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606 > >> -cp eclipse/plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar > >> org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 > >> -clean -debug --launcher.library > >> > plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.0.v20070606/eclipse_1017a.so > >> -startup plugins/org.eclipse.equinox.launcher_1.0.0.v20070606.jar > >> -vm ./soylatte16-i386-r2/bin/java -keyring ./.eclipse_keyring > >> -consoleLog -showlocation > >> > >> However, may be I still miss some library at -Djava.library.path, I > >> still get following exception, will anyone have idea of fixing this?: > > > > My two minute solution (just now) was to drop the SWT JNI libraries in > > the java.library.path manually. Eclipse seems to be running fine. > > I couldn't find the original SWT binaries in the eclipse installation > > tree -- does eclipse extract them from a jar? > > > > Also, SoyLatte R2 only supports shared libraries with the standard > > .dylib extension. R3 added a fall-back to Apple's .jnilib. > > > > -landonf On 12/9/07, Jeff Payne wrote: > > Hi all, > Are there directions to run eclipse under SoyLatte? It would really > be helpful. :) > Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20071209/0773fea4/attachment.html From landonf at bikemonkey.org Sun Dec 9 21:04:48 2007 From: landonf at bikemonkey.org (Landon Fuller) Date: Sun, 9 Dec 2007 21:04:48 -0800 Subject: Mac Status Report -- Merge to BSD Repository, AWT Native Toolkit In-Reply-To: <5EFA47DB-12D3-47C9-B7A8-4175CEDFA791@threerings.net> References: <5EFA47DB-12D3-47C9-B7A8-4175CEDFA791@threerings.net> Message-ID: <4E8801FC-F1BF-4580-8C83-942A9F253971@bikemonkey.org> Howdy all, I thought I'd send out a Mac status report -- Hopefully this isn't too off-topic for the varied members of the list =) == Merge to BSD Repository == I've completed the merge of the Mac OS X port to the BSD Java project. I hope that this provides a solid start for Mac OS X in OpenJDK. With this work done, I've split Mac OS X development into two branches: Development - Integration with Mac OS X-specific technology (native AWT, etc.) http://hg.bikemonkey.org/javasrc_1_6_jrl_darwin/ Stable - A baseline Mac OS X port without additional native integration. Synchronized with the BSD repository. http://hg.bikemonkey.org/javasrc_1_6_jrl_darwin_stable/ == AWT Native Toolkit == I've a bit of time working on a native AWT toolkit. My initial tasks have been: - Running the Cocoa event loop on the 'main' (first) thread. - Getting a window on the screen. - Drawing to the window. The first two items are done -- It's possible to display a basic AWT window (CPanelPeer, CWindowPeer), but not draw to it. In pursuit of drawing, I've begun work on implementing a MacGraphicsDevice and a MacGraphicsEnvironment -- my current plan is to leverage the existing java2d OpenGL pipeline, if possible. I'm still getting my head around the best approach to this, especially in relation to resolution independence on Leopard. If you'd like to check out the work, it's available via the development (JRL) mercurial repository: http://hg.bikemonkey.org/javasrc_1_6_jrl_darwin/ The code is currently located in: j2se/src/solaris/classes/sun/awt/mac/ j2se/src/solaris/native/sun/awt/mac/ I will probably need to move the Mac-specific code out of the j2se/src/ solaris directory. One of my goals is to retain support for both the X11 and the CG/Cocoa AWT toolkits. The build only AWT, you can cd to j2se/make/sun/awt and run: make ALT_BOOTDIR=/System/Library/Frameworks/JavaVM.framework/Home \ ALT_MOTIF_DIR=/opt/local SYS_CFLAGS="" LANG="C" JAVA_HOME="" CLASSPATH="" \ LD_LIBRARY_PATH="" MAKEFLAGS="" SKIP_COMPARE_IMAGES="YES" \ BUILD_DEPLOY="false" ALT_DEVTOOLS_PATH=/usr ALT_CUPS_HEADERS_PATH=/ usr/include \ HOTSPOT_BUILD_JOBS=5 PARALLEL_BUILD_JOBS=5 \ ALT_HOTSPOT_CLIENT_PATH=/usr/local/soylatte16-i386-1.0/jre/lib/i386/ client/ \ ALT_HOTSPOT_SERVER_PATH=/usr/local/soylatte16-i386-1.0/jre/lib/i386/ server/ This will output a working JVM in j2se/build/bsd-i586. For the initial build, you make need to run make from top-level j2se/make directory. Cheers, Landon From puybaret at eteks.com Mon Dec 10 14:07:36 2007 From: puybaret at eteks.com (Emmanuel Puybaret) Date: Mon, 10 Dec 2007 23:07:36 +0100 Subject: Feasibility of integrating an Aqua interface In-Reply-To: <49198660-608F-4BBF-9586-80585019F276@bikemonkey.org> Message-ID: Hi, Here's a first draft of an AWT Toolkit based on SWT 3.3 lib : http://www.eteks.com/swttoolkit/swttoolkit-0.0-src.zip This file contains README.TXT and build.xml files detailing how to use it. Even if there's still a lot of missing features, all AWT components are implemented (even the new Desktop and Tray API), and the small SWTToolkitTest class allows you to test them. You should note that the provided GraphicsEnvironment is buggy : when you try to draw some texts in a Canvas, the JVM crashes abruptly (in the provided test class, click on "Draw It" button and then on the "Text" radio button). *But* with default soylatte GraphicsEnvironment, it works (but it requires a X11 display that is in fact used only for offscreen drawing). I hope this will help porters like Landon Fuller who wants to port AWT Toolkit to Native Mac OS X. The basic idea is that any call to SWT (and //?TODOs ;-) should be replaced by a call to a native feature. Any advice and contribution (a nicer test class before all) are welcome. Have fun ! Cheers, -- Emmanuel PUYBARET Email : puybaret at eteks.com Web : http://www.eteks.com From lnelson at llnl.gov Mon Dec 10 17:02:46 2007 From: lnelson at llnl.gov (Leif Nelson) Date: Mon, 10 Dec 2007 18:02:46 -0700 Subject: soylatte and java.net.preferIPv4Stack=true In-Reply-To: <74534C17-916C-4F2D-8D17-0CA5CA2BABBA@bikemonkey.org> References: <475829DA.7090000@llnl.gov> <74534C17-916C-4F2D-8D17-0CA5CA2BABBA@bikemonkey.org> Message-ID: <475DE1B6.4060601@llnl.gov> Hey Landon- I re-built the jdk with your patch. Appserver startup time for the 10.1.3.3 OC4J container went from 136 seconds (soylatte-1.0) to 7 seconds (soylatte-patched). Startup time for 10.1.2.0.2 OC4J container went from 72 seconds (soylatte-1.0) to 3 seconds (soylatte-patched). Those numbers for the patched soylatte match (almost exactly) what we get from java 5. Thanks so much! -Leif Landon Fuller wrote: > > On Dec 6, 2007, at 8:56 AM, Leif Nelson wrote: > >> Also, each subsequent invocation of InetAddress.getLocalHost() >> takes another 8 seconds, and apparently this method is called several >> times! I did some tests on several macs running both Tiger & Leopard >> with java5 and java6 to demonstrate the issue. >> After some tracing with -Djava.net.preferIPv4Stack=true, I found that >> the time is all taken up inside of the native method: >> java.net.Inet4AddressImpl.getLocalHostName(). >> >> If I trace with -Djava.net.preferIPv4Stack=false (the default), I >> found that the native method >> java.net.Inet6AddressImpl.getLocalHostName() gets called instead >> returns very quickly. >> >> I hope this narrows it down enough to find out what's wrong. :-) > > Thanks! > > I tracked it down to this copy/paste bug in the BSD-specific code > (which I believe I wrote some time ago, so it's my bug) > error = getaddrinfo(hostname, "domain", &hints, &res); > > The "domain" service argument causes getaddrinfo() on Mac OS X to make > (time consuming) MDNS SRV requests for the service: > 12:16:03.619145 IP 10.0.50.246.mdns > 224.0.0.251.mdns: 0 SRV > (QM)? _domain._udp.max.local. (40) > > The service argument should have been NULL. I committed a fix for this > upstream, and will include it in the next release: > landonf at max:/tmp> /tmp/j-build/bsd-i586/bin/java > -Djava.net.preferIPv4Stack=true TestHostName > Found: 10.0.50.246 in: 9 ms. > > Patch: > http://hg.bikemonkey.org/javasrc_1_6_jrl_darwin_stable/rev/219cd1380f35 > > Thanks again for the report, > -landonf > From klssrfr at cox.net Mon Dec 10 20:57:03 2007 From: klssrfr at cox.net (Jeff Payne) Date: Mon, 10 Dec 2007 20:57:03 -0800 Subject: Web Start Message-ID: <18B9D51D-44EC-403F-A2D9-BB8A69EB7F38@cox.net> Thanks for all the help so far. Eclipse going, compiling, running, etc. Happy camper! Any information on running a Web Start application? Jeff From dalibor.topic at googlemail.com Tue Dec 11 04:02:55 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Tue, 11 Dec 2007 13:02:55 +0100 Subject: Web Start In-Reply-To: <18B9D51D-44EC-403F-A2D9-BB8A69EB7F38@cox.net> References: <18B9D51D-44EC-403F-A2D9-BB8A69EB7F38@cox.net> Message-ID: <475E7C6F.8030801@gmail.com> Jeff Payne wrote: > Thanks for all the help so far. Eclipse going, compiling, running, > etc. Happy camper! Any information on running a Web Start application? > Jeff > The webstart & plugin code has not been opened up yet. You may want to try netx as a substitute. cheers, dalibor topic From bryan at varnernet.com Mon Dec 17 10:45:02 2007 From: bryan at varnernet.com (Bryan Varner) Date: Mon, 17 Dec 2007 13:45:02 -0500 Subject: Proposal: Haiku port of OpenJDK In-Reply-To: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> References: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> Message-ID: Members of the porters group, It's been over a week since the submission of this proposal, and since the deadline for feedback is now only four days away, I feel like I should try and jump-start some discussion. > # Past achievements > * A working, native AWT that uses the BeAPI. Most of Java2D is > implemented. I dare you to find a cleaner AWT implementation! As evidence, I'd like to submit the following screen-shots: http://bryan.varnernet.com/files/HolyBlitBatman.png http://bryan.varnernet.com/files/awt_arc.png http://bryan.varnernet.com/files/awt_blink.png http://bryan.varnernet.com/files/awt_clock.png http://bryan.varnernet.com/files/awt_wireframe.png http://bryan.varnernet.com/files/yahoo_02.png > * Ability to run SwingSet, Java2D demos, JBoss, Tomcat, etc. (I don't have any screen-shots of the j2ee servers) Oh look, a popular Swing application http://bryan.varnernet.com/files/BeOS_jEdit_01.png http://bryan.varnernet.com/files/BeOS_jEdit_02.png And video of SwingSet and Java2D demos' running: http://youtube.com/watch?v=yVwc-ZSRMwQ As you can see, we had a lot working with our effort to port 1.4.2 So please, discuss if you will. Feel free to ask us detailed questions. If you have any doubts about our abilities to effectively execute a port now is the time to bring them up. We want to do this work and we'd like to know what those of you voting will need to submit a positive vote. Help us help you. :-) Regards, -Bryan Varner From revol at free.fr Mon Dec 17 13:42:57 2007 From: revol at free.fr (=?windows-1252?q?Fran=E7ois?= Revol) Date: Mon, 17 Dec 2007 22:42:57 +0100 CET Subject: Proposal: Haiku port of OpenJDK In-Reply-To: Message-ID: <1925829722-BeMail@laptop> Hi there, just as an introduction, I'm Fran?ois Revol, aka "mmu_man". I've ported numerous *nix apps to BeOS (and now Haiku), like ffmpeg, PearPC, bzflag... XEmacs (bow before me :p)... > > * A working, native AWT that uses the BeAPI. Most of Java2D is > > implemented. I dare you to find a cleaner AWT implementation! > > As evidence, I'd like to submit the following screen-shots: It is worth mentioning BeOS had several issues which made the port difficult: - lack of mmap() even though it could be emulated to some extent, - no mprotect() (areas protection could only be changed globally, not per page), - quite old gcc (2.95) due to the C++ API locking us to the old ABI. - and I'm not sure but maybe the vm mapping probably didn't help as well (userland starts at 0x80000000). This made it uneasy to really finish the port and publish it. Haiku does not have all those issues, except gcc because we want to maintain binary compatibility, but it is compilable with gcc4 as well. So hopefully some hacks required under BeOS won't be necessary anymore. Fran?ois. From andrewbachmann at gmail.com Tue Dec 18 10:43:08 2007 From: andrewbachmann at gmail.com (Andrew Bachmann) Date: Tue, 18 Dec 2007 10:43:08 -0800 Subject: Proposal: Haiku port of OpenJDK In-Reply-To: <1925829722-BeMail@laptop> References: <1925829722-BeMail@laptop> Message-ID: <9cf4bb560712181043v2886df30w38209f8788b38d72@mail.gmail.com> Hello all, I am interested in working on the port for Haiku/BeOS. As one of the main developers (with Bryan) for the BeOS port of 1.4.2, I did the following: 1. ported bootstrap applications (I used jikes for our bootstrap compiler) 2. ported the hotspot vm (I did nearly all of this part of the work) 3. developed the AWT design with Bryan 4. implemented many controls for AWT 5. used our port in my day-to-day development for my job I had already finished some of the work from the current openjdk sources related to bootstrapping and the build system but unfortunately I had a hard drive crash earlier this year that wiped it out. I don't think it will take that long to replicate once we get going though. Andrew Bachmann P.S. For some of my other BeOS work see: http://www.bebits.com/devprofile/3520 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20071218/96dc9727/attachment.html From dalibor.topic at googlemail.com Thu Dec 20 15:43:49 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Fri, 21 Dec 2007 00:43:49 +0100 Subject: Proposal: Haiku port of OpenJDK In-Reply-To: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> References: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> Message-ID: <985bee770712201543m7937c70fu7dfc1c552252764a@mail.gmail.com> On Dec 7, 2007 8:21 PM, Bryan Varner wrote: > # Past achievements > > The results of our Java port to BeOS were never released (mainly to the > demise of BeOS), but nevertheless included the following achievements: > > * Bootstrapping the 1.4.2 build using jikes and a javah replacement > written in C++. > > * A working, native AWT that uses the BeAPI. Most of Java2D is > implemented. I dare you to find a cleaner AWT implementation! > > * Ability to run SwingSet, Java2D demos, JBoss, Tomcat, etc. > > * 1:1 BeOS native threading model -- which isn't pthreads. > Your achievements are quite impressive, indeed. Since I was the only group member present at the IRC chat, and no one else seems to be taking the bait to fire up the discussion threads, I'll ask a bunch of questions that I think we discussed on IRC already, so that other members of the group have the same access to information. Do you intend to reuse existing code from the 1.4.2 effort for the port of OpenJDK? In that case are all the authors of the code 'on board' and are in the process of signing the SCA? If you intend to reuse existing code, does it include third party code developed outside the porting project? > # Goals of the project > > Our ultimate goal is to have a JCK compliant JDK for Haiku that could be > merged upstream. Initially, our port will focus on support for the x86 > processor line. Haiku has the (long-term) intention to support additional > architectures. As these are added to Haiku, our intent would be to add > support to these in the OpenJDK as well. A consistent user experience > across architectures with Haiku is important to us. > > In an ideal world, our port will be ready in time for the Java 7 release. > We will do what we can to make that a reality. I think that's a great goal, and I hope that the Haiku port will achieve it. > Speaking for the Haiku Java team, I respectfully ask that you consider our > proposal to port OpenJDK to Haiku. If you have any questions, be they > technical, organizational, or otherwise, feel free to direct them my way. I'd just like to apologize for taking a lot of time to get back to this thread. I was hoping we'd see a more lively discussion, but I assume that the screenshots and videos of your team's previous efforts spoke for themselves. ;) I'd be very happy to see the Haiku porting project inside OpenJDK. If no one else stands up, then I'll submit it formally early next week to announce & discuss list, and call for a vote to sponsor the proposal within this group. cheers, dalibor topic From bryan at varnernet.com Thu Dec 20 16:56:24 2007 From: bryan at varnernet.com (Bryan Varner) Date: Thu, 20 Dec 2007 19:56:24 -0500 Subject: Proposal: Haiku port of OpenJDK In-Reply-To: <985bee770712201543m7937c70fu7dfc1c552252764a@mail.gmail.com> References: <15184.162.95.80.197.1197055267.squirrel@mail2.webfaction.com> <985bee770712201543m7937c70fu7dfc1c552252764a@mail.gmail.com> Message-ID: <476B0F38.5060906@varnernet.com> > Do you intend to reuse existing code from the 1.4.2 effort for the port > of OpenJDK? > What makes sense to, and what we can, yes. The core class libraries were handled by Andrew and myself, we'll certainly want to use as much of that as possible. The Java2D implementation we had was heavily stubbed in places, and quite hackish in others, so much of that will likely be re-engineered / re-written now that we have full, unfettered access to the app_server (windowing server) in Haiku. There was a hack in the BeOS Java2D & Graphics object implementation that tracked dirty regions and would only repaint the smallest portion of a surface as was necessary. We'll reuse as much of the hotspot code as possible as well, since Andrew pretty much single-handedly pulled that off. This time, I'm in a better state to hopefully contribute more to that end. The HPI layer may need to be excised. I'm not sure who did (or how much work) was involved in the HPI portion. My impression is that it was fairly straightforward to handle, and I'm sure our team won't have any trouble filling that in. My recollection is that it came from a fellow named Clay who lives somewhere in Tennessee... > In that case are all the authors of the code 'on board' and are in the > process of > signing the SCA? > All except for Clay, who's code we won't use / migrate if we can't get in contact with him. All the files he ported had his company copyright as boilerplate from what I recall, so it's easily distinguishable. Since Andrew's HD crash, I may be the only one with a building tree on a working machine. I plan to send Andrew a backup, since he'll also recall what was developed by us last time around. I'd be uneasy letting folks who weren't involved before try to make judgement calls about what can and cannot be included. As for Andrew and myself, I think the policy will be 'when it doubt, leave it out -- and re-write it.' > If you intend to reuse existing code, does it include third party > code developed outside the porting project? > There were no commercial dependencies, and most of what we needed to include on BeOS R5 is now included with Haiku in the default image. We should have fewer dependencies than our previous attempt - which needed librealpath, libcondvar, cpio, and I know I'm forgetting another one. >> Speaking for the Haiku Java team, I respectfully ask that you consider our >> proposal to port OpenJDK to Haiku. If you have any questions, be they >> technical, organizational, or otherwise, feel free to direct them my way. >> > > I'd just like to apologize for taking a lot of time to get back to this thread. > I was hoping we'd see a more lively discussion, but I assume that the > screenshots and videos of your team's previous efforts spoke for > themselves. ;) > No problem, and we thank you! > I'd be very happy to see the Haiku porting project inside OpenJDK. If > no one else > stands up, then I'll submit it formally early next week to announce & > discuss list, > and call for a vote to sponsor the proposal within this group. > Why wait? Let's go! ;-) -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20071220/b335238a/attachment.html