Bugzilla Bug 159780

no emerge java builds available for sparc 32 or 64 systems. java is a mayor
feature for me. if java will not be available for gentoo i would have to
install another system (maybe solaris 10). my wish would be would be sun java
1.5.x on sparc

Leave the restrict bug checkboxes alone if you have no clue. Thanks.

Not going to happen for now; java support has been dropped intentionally.See
Bug 102816, Comment #1 and others.

(In reply to comment #0)
> no emerge java builds available for sparc 32 or 64 systems. java is a mayor
> feature for me. if java will not be available for gentoo i would have to
> install another system (maybe solaris 10). my wish would be would be sun java
> 1.5.x on sparc
> 
Ferris McCormic <fmccor@gentoo.org> asked me to open this bug. if java will not
be available,  gentoo is dead for me on my sparc machine and all other machines
i have. as i wrote, it is a mayor feature and suns java is no longer "closed"
source. 
please excuse me if i did do something wrong with some checkboxes. 

Please provide a link or other information showing where the sun java sources
are if they are now available (if you know).  This would make it easier for us
to find them.  If you don't know, please say so, but even if you don't know,
just telling us if the open source for java is available yet would be a big
help (assuming you know that. :) ).

Thanks for any information you have --- we prefer to be lazy when possible. :)

To quote David Herron from Sun [1]
"Clearly in the JDK sources we have code that supports Linux, and we have code
which supports SPARC, but not these two at the same time. It turns out to be
a little difficult to bring those two together.
I would think that in the not too far distant future there could be
project(s) like you say working together in the openjdk [2] project to
support the JDK on new architectures and maybe new operating systems."

[1] http://archives.gentoo.org/gentoo-java/msg_01927.xml
[2] https://openjdk.dev.java.net/

So far you can get the sources of hotspot virtual machine on openjdk site. Java
bundled classes that come with the JVM aren't opensourced yet, but I believe,
for porting to sparc, the hotspot VM is the important thing to port. Maybe
there's some effort already, but I don't know about it... try searching the
site (community pages, maillists...)

You also could feasibly try kaffe or jamvm or cacao for open source vms.
Probably the later two would be more appealing, as they do support the
gnu-classpath generics branch.

Of course, someone would have to do a bit of work to a) get those working as a
build-vm regardless of platform and b) get those working on sparc.

As to Comment #4 : Thanks for the clarification and for the links.  David
Herron did respond by email to  Petteri R

As to Comment #4 : Thanks for the clarification and for the links.  David
Herron did respond by email to  Petteri Räty <betelgeuse@gentoo.org> on this
topic, but in his response, he did not really provide the information you did: 
All he said was (1) java-on-sparc is solaris only, (2) after opensource project
for java is complete, it might be possible to work on sparc/linux+sun-JDK.  He
did not hint at the difficulties you mentioned, so he came across rather
poorly.  (Of course, although sun does support Linux on some of their
architectures, sparc is not one of them.)

As to Comment #5 :  Thanks for the specific packages; I was about to start a
search for such things, so you have saved me some time.  For your information,
kaffee has some problems on sparc; I have built it on sparc, but others report
difficulties.  Also, sablevm builds and works fine, but it seems to be no
longer under development, and it is not complete enough to satisfy our needs.

Let's do a reality check here.
Blackdown did up to 1.4.1 for Linux/SPARC which has the problems mentioned
before (security, stability). For other platforms (amd64/x86) blackdown did up
to 1.4.2.x. AFAIK blackdown had some special deal with Sun where they got some
source and ported/built for other platforms.
Sun did their own for Solaris/SPARC, Solaris/x86, Linux/x86 and Linux/amd64
(maybe some other but not Linux/SPARC).
Blackdown did the magic to get it running on Linux/SPARC, but since this is
basically closed-sourced (the 1.5.x code opening from Sun probably isnt'
retroactive). This means the Linux/SPARC specifics (which probably mean some
assembly work) have to be redone.
I think it's unlikely a gentoo developer will do this work.

I would guess as well that sun sparc/java runs the code portions in 64-bit
userland, and this combined with the likely assembler code makes a mess.  No,
given Comment 4, I don't think any sparc developer wants to look at sun.

(In reply to comment #7)

> Blackdown did the magic to get it running on Linux/SPARC, but since this is
> basically closed-sourced (the 1.5.x code opening from Sun probably isnt'
> retroactive). This means the Linux/SPARC specifics (which probably mean some
> assembly work) have to be redone.

Sun will not be opening 1.5.x with the current plans.. It will probably be some
1.7* alpha/beta that will be opened.

Frankly i don't understand why this bug is open, it's pretty obvious this won't
happen in a weeks (probably even months) timeframe - seems more like a wish bug
than anything else.
And wishing won't make it happen no matter how many people do. This requires
source and people with a lot of time in their hands to port to Linux/SPARC
specifics (which probably includes assembly too) and testing. I for one don't
volunteer, and i don't think anyone CC'ed on this bug or gentoo dev will.

(In reply to comment #10)
> Frankly i don't understand why this bug is open, it's pretty obvious this won't
> happen in a weeks (probably even months) timeframe - seems more like a wish bug
> than anything else.
> And wishing won't make it happen no matter how many people do. This requires
> source and people with a lot of time in their hands to port to Linux/SPARC
> specifics (which probably includes assembly too) and testing. I for one don't
> volunteer, and i don't think anyone CC'ed on this bug or gentoo dev will.
> 

While it's open, it's an aid to me.  I'd like to get as much information as I
can, because there are 1 or 2 users interested in helping with/doing this.  I'd
like to be able to say "here are a couple java open source packages to look at"
or "it looks hopeless."  And people who know things can help us make that
determination.  It's pretty clear that sun is a non starter,  but I'd prefer to
keep this open long enough to make that determination.  For example, sablevm
runs just fine on sparc, but it is out of date (at the blackdown-1.3.x level,
say) and apparently not supported upstream anymore. It's also pretty
lightweight as javas go.  It's probably not a good candidate, although we might
have users who would like to look at it.  I'm pretty sure there should be
similar projects out there someplace, Comment 5 gives some ideas, and so on.

I agree that this bug will probably be closed as "Can't do", but I'd like to
wait a bit longer.  I believe just knowing definitively what is going on is a
service to our users;  I'm willing to assign the bug to myself if you like.

(In reply to comment #5)
> You also could feasibly try kaffe or jamvm or cacao for open source vms.
> Probably the later two would be more appealing, as they do support the
> gnu-classpath generics branch.
> 
> Of course, someone would have to do a bit of work to a) get those working as a
> build-vm regardless of platform and b) get those working on sparc.
> 
Small update.  cacao liiks like is should work, but there are two difficulties.
 Building it requires a working javac, which is a problem, and it has a bit of
64-bit assembly code which is also a problem.  Neither is insurmountable, but I
am putting it on hold because (1) I don't have a good javac lying around; (2) I
don't want to bother with the assembly code and other 64-bit issues right now. 
(Notice that cacao-0.97 at least is sparc-aware (this version is not in the
tree).)

jamvm looks more promising.  To build it, I need to dig out (again, sigh) the
assembly code for atomic read/write and test&swap.  I;ll do that in a day or so
to see what we end up with.

In both cases, we first need to do some keywording in an overlay and then
unmasking in order to install jikes and gnu-classpath-0.92, but once that is
done, both build and install without incident.

(In reply to comment #13)
>
> Small update.  cacao liiks like is should work, but there are two difficulties.
>  Building it requires a working javac, which is a problem, and it has a bit of
> 64-bit assembly code which is also a problem. 

Cacao should be buildable with jikes.

(In reply to comment #14)
> (In reply to comment #13)
> >
> > Small update.  cacao liiks like is should work, but there are two difficulties.
> >  Building it requires a working javac, which is a problem, and it has a bit of
> > 64-bit assembly code which is also a problem. 
> 
> Cacao should be buildable with jikes.
> 
Cacao is mostly buildable with jikes if you set enough environment variables. 
Bigger problem with cacao is that it insists that its sparc/linux version run
as a 64-bit application, which is not supported (changing this requires
replacing some assembly code --- a task I'm holding off on.).  There might be
configure options to get around this --- I haven't explored that yet (you would
have to tell it not to use any assembly code).

jamvm will build if you modify the configure file a bit to force USE_FFI,
supply a sparc.h header defining the atomic operations, and an os/linux.sparc
directory (with not much in it).  Whether it comes close to working I don't
know yet.  But it's very light-weight, so I have hopes It's actually tiny.

Status Update:

- This seems to be the only page with information on Java/Sparc/Linux at all,
so I'll add my knowledge here

- gcc 4.3 will support Java 5 language features, it has just entered "stage 2",
so a release is at least 4 more month away.

- Java 1.6 and 1.7 from sun are available as GPL. The main site is:
http://openjdk.java.net/ , the site for 1.6 is https://jdk6.dev.java.net/ , for
1.7 it is https://jdk7.dev.java.net/

However: Building a JDK/JRE still depends on some binary plugins, which are
available for solaris/sparc and linux/x86, but not linux/sparc.

Two more links with information on the openjdk:

http://blogs.sun.com/tmarble/entry/debconf7

http://icedtea.classpath.org/wiki/Main_Page

IcedTea should be able to provide this soon.

(In reply to comment #18)
> IcedTea should be able to provide this soon.
> 

Good to know.  We'll keep watching for gcc-4.3. :)

I have IcedTea running on gentoo SPARC, I have a binary package ready to upload
somewhere, just need to find a good place to hold a 140MB file.

I mentioned this on the #gentoo-sparc IRC channel and was told since it was
gentoo there was no interest in binaries and to come here and explain how I
built it etc etc.

Well, with the current status of Java on SPARC, there is no way to automate
what I did to get this built. I used some rather hackish scripting to fire most
bytecode compilation jobs over to x86 using SSH, a backchannel via NFS, some on
the fly modification of the compiler commands and a fair bit of hand holding
etc. This took me a week or so and is not the kind of thing that lends itself
to easy (or any) ebuild creation.

I don't see a binary being an issue for gentoo in this case, since, after the
binary is in place, Icedtea will happily compile from source using itself
(without any hackery), then the binary could be removed. And since to use Sun,
Ibm, etc... jdks on other arches have to use binaries anyway, is this a big
issue??

So If someone can point me at a location online where people will easily be
able to get at the file, I'll upload it.

If there's no interest I'll just keep it to myself and you guys can wait for
some other jdk to come up to speed and allow you to build Icedtea :P


Looky looky:

# java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b10)
OpenJDK Client VM (build 1.6.0-b10, mixed mode)

And the actual icedtea ver is:
icedtea-6.1.3_pre20080530


Other than building itself, I tested a few apps.

JBidwatcher = Runs the same as on IcedTea x86 (can't login due to missing sun
security stuff)
Jedit = Works fine.
Jripper = Looks like it works, did no further testing with it.
jIRCii = Works, and is how I made my announcment on #gentoo-sparc
frozen-bubble = Works fine.

So who want's it and where would you like me to shove it!!!  :)

Dylan

Dylan,

I want it! And I'd be willing to host it (of course, on a Linux/Sparc machine)
if there is not too much traffic.

How did you do it? Did you need to patch the jdk to add the hotspot stuff for
linux/sparc, or have they finally managed to split this into arch / os ? Could
you post step-by-step (or at least some generic) instructions? How about
compiling it with ecj for bootstrapping? 

Max

(In reply to comment #21)

Max,

> Dylan,
> 
> I want it! And I'd be willing to host it (of course, on a Linux/Sparc machine)
> if there is not too much traffic.

That's great, where should I place it.

> How did you do it? Did you need to patch the jdk to add the hotspot stuff for
> linux/sparc, or have they finally managed to split this into arch / os ? Could
> you post step-by-step (or at least some generic) instructions? How about
> compiling it with ecj for bootstrapping? 

First time around yes, I had to apply the patches for sparc, I was about to
look at doing the scary stuff myself but Sun released patches just in time,
these were put into openjdk 1.7, but had not been backported to 1.6 at the
time. Here is info on the patches:

Initial release of patch:
http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/435e64505015

A Ubuntu packaged copy of the patch is available here, it's the second version
of their package and sets sparc builds to use -fPIC:
https://launchpad.net/ubuntu/intrepid/+source/openjdk-6/6b09dfsg-1ubuntu2

I had started originally with the ebuild in the gentoo java overlay, using the
included versions of icedtea and the jdk.

My build process was simply a small bash script locally and another one
remotely.  It relied on the x86 box having an NFS mapping back to the portage
build dir on the sparc. I could replace any command on my sparc system with a
symlink to my bash script, it would then ssh over to the x86 box (modify the
command if needed with sed) and run the command that should have run on the
sparc box.

I set this up to map gcj (mapped to java), java, javac back to the x86, when a
problem section in the build was comming up, i flipped to the external build,
then back after the problem.

With my build process and a lot of hand holding I had gotten a long way into
the compile, well past hotspot and all the classes, it died where it jars
everything into the huge RT.jar, the reason being that somewhere along the line
my build system pulled in a bunch of sun class files from x86, I'd done this
just to keep the compile happy at an earlier point as it was non critical, I
just wanted to see how far the build would go.

At this point I copied what I had over to /opt and set it up for java-config-2.

I found the Ycarus ebuild for icedtea-6.1.3_pre20080601 here:
http://gentoo-overlays.zugaina.org/java-overlay/dev-java.html.fr#icedtea

And it builds, it just builds!! No x86 jumping to help out, and almost no hand
holding (stupid webplugin). The patches from above look to have been backported
into openjdk 1.6 so that was nice.

After everything is done and built, the silly thing finds the webplugin and
tries to copy it into /blah/blah/sparc64/blah/sparc64 instead of
/blah/blah/sparc/blah/sparc. Since the file was indeed 32bit I just fixed it
with symlinks and did an "ebuild blahblah.ebuild compile" and it went right
through to "compile completed" then removed the symlinks.

I've tested a some more apps now:

FTP-Go  - Not in portage - Works fine.
http://www.cellspark.com/ftp.html

Mercury Messenger - Not in portage - Works fine.
http://www.mercury.im

Dylan

Just a note for anyone who wants to build icedtea from an ebuild.

Every ebuild I've seen contains:
--with-parallel-jobs=$(grep -s -c ^processor /proc/cpuinfo)

This will return 0 as the word "processor" is not in the output of "cat
/proc/cpuinfo"

To test on sparc you can force it to 1 or whater to mach your CPU count:
--with-parallel-jobs=1

Although it would possibly better to change it to:
--with-parallel-jobs=$(echo `ls /sys/devices/system/cpu` | grep -c ^cpu)

That should keep sparc and x86 (and others) happy. Does everyone havs /sys
these days?

dylans package can be downloaded here:

http://ochsner.dps.uibk.ac.at/icedtea-6.1.3_pre20080530-gentoo-sparc.tar.bz2.torrent

I'll try to keep this seeded until it is properly implemented into gentoo.

Max

Thanks for that max, I'll fire up azureus and help seed.

And I should have tested the command in my last post, here is a working one.
Detects CPU cores at least sparc and x86, should work on all arches with /sys

--with-parallel-jobs=$(echo `ls -1 /sys/devices/system/cpu | grep -c ^cpu`)

Yes, we are interested.
So, I suppose that what the ebuild for IcedTea should look like is that if we
are on sparc, then one of the "source files" is your binary and then the ebuild
uses that to rebuild itself.  That should be easy enough to do I would think. 
If you can prepare such a thing, I'll look at it.

Or, if you can provide an ebuild which just installs your binary, that is
possible too.  After all, that's what happens with sun or blackdown --- it's
just that they don't provide sparc support.

Of the two I prefer the first, but I'll look at either.

I'll look more closely at everything next week, but many thanks for your
efforts.  We'll try to find a way to make this "official" because there is a
lot of interest in our community.  Feel free to contact me directly on IRC or
via email.

Thanks again,
Ferris

Created an attachment (id=155937) [details]
ebuild for sparc icedtea binary

Created an attachment (id=155939) [details]
Environment file, copy to /files 

The ebuild above is simply for installing the binary.

Although I do like the idea of pulling in the binary at compile time to do it's
job, I'd rather use a different much smaller binary. I'll look into creating a
mini-jdk just for the icedtea installation.

Following this post you'll find a version of the Ycarus ebuild that's fixed for
sparc.

Created an attachment (id=155945) [details]
ebuild to build from source (after the bin is installed) fixed for sparc

I'm going to look at this on 9 or 10 June.  Please prod me on IRC or by email
as appropriate.  I might not notice bug changes.  

1)  icedtea-jdk-bin-6.1.3_pre20080530.ebuild can be made to work, although it
requires some tweaking.  Mostly, it would be better SRC_URI actually were
SRC_URI="path-to/icedtea-6.1.3_pre20080530-gentoo-sparc.tar.bz2"
like in the icedtea ebuild.

2) For icedtea, there are a couple .diff files needed:
   epatch "${FILESDIR}/openjdk-6_b10.diff"
   epatch "${FILESDIR}/bootstrap_fix-heapsize.diff"

(In reply to comment #32)

Hi Ferris,

I've only just gotten back onto this today, real life jumped in the way so to
speak, and then my ISP went bust and pulled the plug on everyone :(

> 1)  icedtea-jdk-bin-6.1.3_pre20080530.ebuild can be made to work, although it
> requires some tweaking.  Mostly, it would be better SRC_URI actually were
> SRC_URI="path-to/icedtea-6.1.3_pre20080530-gentoo-sparc.tar.bz2"
> like in the icedtea ebuild.

Sorry about the SRC_URI, I didn't know portage would scream at me if it was
blank, I removed it at the last minute since the file was hosted on bittorrent
rather than the www. Should I just put a broken path there for now or what? At
least it will then merge, provided the file is present in distfiles.

> 
> 2) For icedtea, there are a couple .diff files needed:
>    epatch "${FILESDIR}/openjdk-6_b10.diff"
>    epatch "${FILESDIR}/bootstrap_fix-heapsize.diff"
> 

Yes, naughty me again, I did make reference to where they were to be found,
though I should have just attached them. Will do now.

I'm just updating things on the sparc box now, will come back with some
updates.

Created an attachment (id=157813) [details]
openjdk-6_b10 patch for above mentioned source ebuild of icedtea

Created an attachment (id=157815) [details]
bootstrap_fix-heapsize patch for above mentioned source ebuild of icedtea

Those patches are correct, although icedtea certainly has a lot of
dependencies.  As for the torrent source file.  You could make that the source
file and let emerge fetch it.  I don't know if emerge knows how to process a
torrent file or not.  If not, you could make that part of the src_unpack step.

I've tested the icedtea-jdk-bin ebuild and it seems to work. I had to add "cp
/my/folder/${icedtea}.tar.bz2 ./" to src_unpack to help portage to find the
file. After that everything seemed to work fine. I tested java with some
hello-world application and it seemed to work.

When i tried to emerge the icedtea ebuild, dev-java/sun-jdk-1.6.0.11 failed to
emerge. It can't find/unpack the necessary files. Are there missing the
src-files for sparc architecture? 

I would host the icedtea-6.1.3_pre20080530-gentoo-sparc.tar.bz2 if you want me
to (IPv4 and native IPv6 connection).

EoD,

I'd be happy if I don't have to host it anymore - I am no longer using it, and
the only reason I keep this around is for other people to find it.

However, I currently see no point in moving it to another "personal" site,
because the result would just be the same state as we have now - What should
happen is that this gets properly integrated into gentoo and on the normal
gentoo mirrors. (Unfortunately I have neither the time nor the access rights to
do this)

So for now I would recommed to keep it seeded - the tracker should pick up your
site and add it as a place to download.

Max

I had some problems downloading the torrent file manually and placing it
somewhere (i still don't know where it should have been). It would be much
easier to host it on http/ftp, as the ebuild could download the file
automatically, without any problems.
And i can guarantee, that the server is maintained at least every day (it's
some kind of semi-official server).

Created an attachment (id=191086) [details]
new virtual/jdk compatible icedtea binary ebuild

This ebuild is based on the ebuild from Dylan Wakefield, with some minor
adjustments and the possibility to download it via ftp instead of torrent (as
max.berger's site seems to be down).

Max,

Thankyou for the effort spent in hosting/seeding the binary for the length of
time that you did, it was very much appreciated.

EoD,

Thankyou for providing the current hosting, it's also very much appreciated.


With the recent interest shown on this topic, I decided to blow the dust of the
Sparc, fire it up and churn out a nice working gentoo friendly build for the
current version of Icedtea6.

Gentoo recently dropped the requirement for a 1.4 JVM, hence, removing on of
the blockers for sparc java.

Icedtea6 in standard portage is only available as a binary, so there should be
no problems if sparc is the same (the source version also builds with only
minor updates to the ebuild).

I'm posting a new ebuild that is based on the current portage
icedtea6-bin-1.4.1 ebuild, it is a drop in replacement and wont cause problems
with other arches, it's simply the ebuild from portage with sparc support
added.

Could this be the trigger for the unmasking of java on sparc, what else is
missing?

Cheers,
Dylan
Said ebuild follows:

Created an attachment (id=193078) [details]
sparc compatible icedtea6-bin-1.4.1 ebuild

This ebuild installs correctly, java-config can set it up properly, and initial
tests show that it seems to be able to handle at least one major java
application (netlogo-4.0.3, a simulation program based on starlogo).  And yes,
this could be the trigger for unmasking java again on sparc.  For that to
happen, I'll need help from sparc people who actually know something about java
(I'm not one of those).  I suppose eclipse is the torture test?

I've been having a bit of a play with icedtea6-bin and the vast majority of
apps that require java now build, simply by keywording them for sparc/~sparc. 

The following is a list of things that have built successfully, this is by no
means an exhaustive list. Just because it built doesn't mean it works, although
in general that is the case.

Anything with native code may need a tweak to the build, things that come to
mind are swt and eclipse. 

The swt ebuild needs a bit of a tweak, I'll post an ebuild for it later. I have
tested swt somewhat with vuze :)

Eclipse (not listed bellow) needs another strand of spaghetti wound through
it's build system, I'll take a look at it and see what I come up with.

Anyway, the list so far:

app-editors/jedit-4.3_pre16
app-editors/jext-5.0
dev-java/ant-1.7.1 
dev-java/ant-antlr-1.7.1-r1
dev-java/ant-apache-bcel-1.7.1
dev-java/ant-apache-bsf-1.7.1-r1
dev-java/ant-apache-log4j-1.7.1
dev-java/ant-apache-oro-1.7.1
dev-java/ant-apache-regexp-1.7.1
dev-java/ant-apache-resolver-1.7.1
dev-java/ant-commons-logging-1.7.1
dev-java/ant-commons-net-1.7.1
dev-java/ant-core-1.7.1-r4
dev-java/ant-eclipse-ecj-3.4
dev-java/ant-javamail-1.7.1
dev-java/ant-jdepend-1.7.1
dev-java/ant-jmf-1.7.1
dev-java/ant-jsch-1.7.1
dev-java/ant-junit-1.7.1
dev-java/ant-nodeps-1.7.1
dev-java/ant-owanttask-1.1-r12
dev-java/ant-swing-1.7.1
dev-java/ant-trax-1.7.1
dev-java/antlr-3.1.3-r2
dev-java/asm-2.0-r1
dev-java/bcmail-1.38-r1
dev-java/bsf-2.4.0-r1
dev-java/cldc-api-1.1
dev-java/commons-daemon-1.0.1-r2
dev-java/commons-dbcp-1.2.2
dev-java/commons-el-1.0-r2
dev-java/commons-pool-1.4
dev-java/dom4j-1.6.1-r3
dev-java/eclipse-ecj-3.4-r4
dev-java/fop-0.94-r1
dev-java/gnu-classpath-0.97.2
dev-java/gnu-regexp-1.1.4-r2
dev-java/hamcrest-core-1.1
dev-java/icu4j-3.8.1-r1
dev-java/iso-relax-20050331-r2
dev-java/itext-2.1.5
dev-java/jarjar-0.9
dev-java/java-config-2.1.8
dev-java/java-config-wrapper-0.16
dev-java/java-getopt-1.0.13
dev-java/javacc-4.2
dev-java/javacup-0.11a_beta20060608
dev-java/jaxen-1.1.1
dev-java/jaxp-1.4-r1
dev-java/jcommon-1.0.16
dev-java/jfreechart-1.0.13
dev-java/jgoodies-looks-2.1.4
dev-java/jsch-0.1.41
dev-java/junit-4.6
dev-java/jython-2.2.1-r1
dev-java/jzlib-1.0.7-r1
dev-java/log4j-1.2.15-r1
dev-java/lucene-1.9.1
dev-java/lucene-analyzers-2.3.2
dev-java/qdox-1.6.3
dev-java/rhino-1.6.5
dev-java/servletapi-2.4-r5
dev-java/stringtemplate-3.2
dev-java/sun-jaf-1.1.1
dev-java/sun-javamail-1.4.2
dev-java/swing-layout-1.0.3
dev-java/swt-3.4-r3
dev-java/tomcat-servlet-api-6.0.18
dev-java/xerces-2.9.1
dev-java/xml-xmlbeans-1.0.4_pre20041217
java-virtuals/jaf-1.1-r1
java-virtuals/javamail-1.0-r1
java-virtuals/servlet-api-2.3
media-video/projectx-0.90.4.00_p26
net-irc/jircii-41
net-p2p/vuze-4.2.0.2
net-p2p/vuze-coreplugins-4.2.0.2
sci-biology/readseq-20080420
virtual/jdk-1.6.0-r2
www-servers/tomcat-6.0.18-r3