1 |
robert burrell donkin wrote: |
2 |
> On 5/4/06, *Joshua Nichols* <nichoj@g.o |
3 |
> <mailto:nichoj@g.o>> wrote: |
4 |
> |
5 |
> (The following is shamelessly yanked from the blog post I just made) |
6 |
> |
7 |
> |
8 |
> <snip> |
9 |
> |
10 |
> *1a)* |
11 |
> /Summary:/ |
12 |
> |
13 |
> Build most of our Java packages with free (libre) virtual machines and |
14 |
> free implementations of public APIs. |
15 |
> |
16 |
> /Background:/ |
17 |
> |
18 |
> Currently, we really only support using a proprietary virtual machine |
19 |
> (ie sun, blackdown, ibm, etc), because packages are likely to fail for |
20 |
> various reason with the open ones. |
21 |
> |
22 |
> For many open apis, such as javamail, java activation framework, |
23 |
> etc, we |
24 |
> have binary packages of Sun's proprietary implementations. In a |
25 |
> number |
26 |
> of cases, there are open implementations. However, our packages |
27 |
> compile |
28 |
> against and run using the proprietary implementations. |
29 |
> |
30 |
> For reasons why one would want to be using Free Java, see the |
31 |
> article on |
32 |
> the Java trap < http://www.gnu.org/philosophy/java-trap.html>. |
33 |
> |
34 |
> As for a practical reason, use of proprietary packages from Sun |
35 |
> and IBM |
36 |
> can annoying for the end user, because in both cases, it requires |
37 |
> placing a fetch restriction on the distfiles. To the end user, this |
38 |
> means that an emerge gets halted until they agree to a license, and |
39 |
> download the files. |
40 |
> |
41 |
> /Goals:/ |
42 |
> |
43 |
> * Build/run all/most packages using free virtual machines |
44 |
> * Build/run all/most packages against free implementations of |
45 |
> public |
46 |
> APIs |
47 |
> * Might want to target specific big name packages, like eclipse, |
48 |
> azureus, tomcat. |
49 |
> * Be able to select between different implementations of the |
50 |
> same apis |
51 |
> |
52 |
> /Tasks:/ |
53 |
> |
54 |
> * Work with upstream of packages that use propertary classes from |
55 |
> the virtual machine (ie com.sun.*, sun.*) |
56 |
> * Work with upstream of virtual machines and packages when |
57 |
> packages |
58 |
> don't compile or run with using free java |
59 |
> * Find and package open implementations of public APIs |
60 |
> |
61 |
> |
62 |
> |
63 |
> /Hurdles:/ |
64 |
> |
65 |
> * Lots of Java packages (300+). It is unknown how many will |
66 |
> need to |
67 |
> be patched. |
68 |
> * Upstream might not care about free java |
69 |
> |
70 |
> * Might not be open implementations of all APIs |
71 |
> |
72 |
> |
73 |
> why the emphasis on software libre? |
74 |
> |
75 |
And I think you're reading too much into what I said. By libre, I really |
76 |
mean open source. |
77 |
> why exclude ASL'd libraries from the effort? |
78 |
ASL? Do you mean the Apache license? In either case, I don't recall |
79 |
saying anything about excluding anything. |
80 |
> why not open source java? |
81 |
> |
82 |
Uh, open source java is EXACTLY what I'm talking about :) |
83 |
> the ASF has already made considerable progress in creating open source |
84 |
> clean room implementations for the major java specifications (harmony, |
85 |
> geronimo, ws). gump and harmony have been working closely with the |
86 |
> classpath and kaffe teams for a number of years now. |
87 |
> |
88 |
Open source java implementations have actually made tons of progress |
89 |
everywhere in the past year or so. |
90 |
> - robert |
91 |
> |
92 |
In the future, be sure to reply on-list. |
93 |
|
94 |
|
95 |
Josh |
96 |
|
97 |
-- |
98 |
gentoo-java@g.o mailing list |