| 1 |
On Sat, 2006-07-08 at 17:12 -0400, nil nil wrote: |
| 2 |
> That makes sense. I mean that, I understand the gentoo philosophy |
| 3 |
> concerning source code, however, I don't think it really applies to |
| 4 |
> java code. Java byte code is supposed to compile the same everywhere. |
| 5 |
|
| 6 |
It has more to do with philosophy, layout, using the latest deps that |
| 7 |
are normally bundled to build any given app. Not so much compile time |
| 8 |
tweaks, optimizations or the other stuff one can do with say C or C++ |
| 9 |
during compilation. |
| 10 |
|
| 11 |
For example diff of compiling an app say with it's bundled log4j v1.2.11 |
| 12 |
or using the current 1.2.13. |
| 13 |
|
| 14 |
> There are very few javac options which will affect the bytecode |
| 15 |
> coming out. If compilation to native code is needed, gcj et al. can |
| 16 |
> handle compiling bytecode. Point being, there's no benefit to |
| 17 |
> compiling from java source (except to native), and if the distributers |
| 18 |
> will compile it for you it only saves cpu cycles. |
| 19 |
|
| 20 |
Java code compiles so fast it's a moot issue. Even something as big as |
| 21 |
Netbeans on slower hardware almost takes more time to unpack than to |
| 22 |
compile. |
| 23 |
|
| 24 |
> The second thing with distributers packing their own jars in I |
| 25 |
> understand. I can only say that if it does waste memory to have extra |
| 26 |
> jars lying around, it's still better to have that and the application |
| 27 |
> than no application at all. At least in my book. A solution could be |
| 28 |
> worked out later to put the jars in their own ebuilds. |
| 29 |
|
| 30 |
Been there done that. Which is why these days any new ebuilds MUST not |
| 31 |
use any bundled jars. If they are not in their own packages, that has to |
| 32 |
occur before the ebuild. Such is life. |
| 33 |
|
| 34 |
The previous state there was a mixture of binaries, most all with their |
| 35 |
own bundled deps. Even if that is already present on the system. It made |
| 36 |
a mess, took a while to clean up, and pretty sure those in charge are |
| 37 |
really against going back down that road. I don't blame them. |
| 38 |
|
| 39 |
> The third thing, and I mention it now to make up for being perhaps |
| 40 |
> overly critical of a process I know very little about, is why I joined |
| 41 |
> this list in the first place. I'd like to help the gentoo-java |
| 42 |
> project. I don't know much about how to help, though, so if anyone |
| 43 |
> could point me in the right direction I'll come back later in a better |
| 44 |
> position to help. |
| 45 |
|
| 46 |
Hit up IRC #gentoo-java @ freenode.net most all of the active players |
| 47 |
tend to lurk there at some point or another. Bug squashing or reporting |
| 48 |
is always welcome. Testing experimental packages providing feedback etc |
| 49 |
is all greatly appreciated. |
| 50 |
|
| 51 |
If you want to do more than that, ebuild contributions are welcome, |
| 52 |
patches to improve existing ones. For those with allot of time, or the |
| 53 |
motivation. We surely could use more Gentoo Java Developers, which I am |
| 54 |
in the process of becoming one. Bit of work and time commitment to get |
| 55 |
to that point. |
| 56 |
|
| 57 |
-- |
| 58 |
Sincerely, |
| 59 |
William L. Thomson Jr. |
| 60 |
Obsidian-Studios, Inc. |
| 61 |
http://www.obsidian-studios.com |
| 62 |
|
| 63 |
-- |
| 64 |
gentoo-java@g.o mailing list |
Archives