[RESEND] Re: [gentoo-java] work on gcj for gentoo

[Hanno Meyer-Thurow <h.mth@web.de>]

On Wed, 22 Feb 2006 19:16:22 +1100
Andrew Cowie <andrew@operationaldynamics.com> wrote:

> On Tue, 2006-02-21 at 10:45 -0500, Joshua Nichols wrote:
> > I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
> > gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
> > that it provides a usable JDK, which it doesn't as it was.
> 
> ... but was hoping to get there some day.

Some news of my overlay

I added
	* shell wrapper scripts for java{,c,doc} to reflect gij / ecj / gjdoc
	* symlinks to jar, javah, rmic (from fastjar, gcjh, grmic)
	* java-config-2 integration with java-config-1 compat
	* PDEPEND on eclipse-ecj and gjdoc

to provide a usable JDK with dev-java/gcj

I also added a Ecj Compiler Adapter and GnuRmic Rmic Adapter
to ant-{core,tasks} which need review. They seem to work.
It is simple code.

Azureus, Beanshell, eclipse-sdk, Xalan and dependencies merged
without issues. OpenOffice.org will need some tweaking for gcj / ecj.
Luckily there is a hack from Arklinux to base the work on.

My todo
	high priority
	* fix issues that pop up (OOo, ...)
	* wait for java-config-2 to get into Portage

	medium priority
	* integrate jar to native

	low priority
	* eclipse-sdk to native

---
I really dislike that java-gcj-compat.
Why? I used it. It is extra work you just do not want.

I just do not want to see it in Gentoo! ;)
---

> > Speaking of which, I think the added compatibility layer (for javac, 
> > java, etc) should be a separate package. I'm not sure if this was your 
> > intention or not. Either way, it would make sense, since you would most 
> > likely be able to use the same layer for different versions of gcj.
> 
> You guys are the devs, so packag{ing,e name} decisions are yours to make
> as you see fit.

Would be a cut and paste from dev-java/gcj then.

> While I prefer the latter name, I am very sensitive to the issue that
> once we call it a jdk (or rather, once java-config allows it to be
> selected) we're in for a nightmare of people's expectations not matching
> what is actually there...
> 
> [shit like "why isn't it magically creating a binary for me? I thought
> GCJ created binaries! Bastards, rant rant rant]

That would be the database / jar to native // java to native work as planned.
I use 'native (nativeonly)' useflag for eclipse-ecj and gjdoc already.

> ... which we'll probably get either way, especially as people
> misunderstand the { dev-java/gnu-classpath version vs gcj's imported
> version of classpath } issue and the { what Free Java is capable of
> these days } issue and the { gcj -C plus gij as JDK vs gcj -c plus gcj
> (link) as native compiler } issue.

True.

We got java{,c}, et cetera, for standard JDK behaviour.
I add 'native' useflag to get native code.

There will be issues, for sure.

> Lots of misunderstanding! Oh well. Doesn't mean we shouldn't carry on
> and leverage what the Red Hat boys are up to.

I set one way to go.
It just needs to be accepted or tweaked to your liking. ;)
Finally, one needs to write the code.
	* which is me
	* ... and maybe some Java programmer that got some
	  extra spare time to waste


Regards,
Hanno
-- 
gentoo-java@gentoo.org mailing list