This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCJ adoption and improving our "PR"


>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:

Bryce> However, I also believe that in order for random Java hackers
Bryce> to see and understand these benefits we must work to "smooth
Bryce> the transition path" for those coming from the traditional JRE
Bryce> development environment. To me this means that gcj must become
Bryce> more robust and easier to use in terms of taking existing
Bryce> applications and getting them up and running quickly.

Yeah.

The vision here, which we haven't communicated all that effectively,
is to turn gcj into a kind of caching JIT.  The idea is that we can
make it very simple to deploy a gcj-compiled application: no
application changes at all, just compile the .jar files to .so files
as-is, perhaps tweak a setting somewhere (to tell libgcj about the .so
cache you just created), and off you go.

So for instance we should be able to naively gcj-compile as a build
step, making it trivial to add gcj support to jpackage RPMs.

I don't see the above as the "very best" approach to building a
gcj-using application.  However, it is an important approach to
support because it means gcj will interface better with non-gcj-aware
packages, and it will be easy for people to give it a try.

Bryce> And then there is the "public relations" issue. From my perspective
Bryce> there is definitely far more going on in the GCJ/Classpath world today
Bryce> than there was, say, 2 - 3 years

One thing I would recommend to everybody is to get out there and give
talks about gcj.  I've gotten a lot of nice feedback from my FOSDEM
talk along the lines of "wow, I never knew gcj could do that".  I
think this sort of thing really does have an impact.

Bryce> So, I propose that we work to improve the website so that it includes
Bryce> wiki-style dynamically updatable content, especially for things like
Bryce> news items, development status, FAQ entries, etc.

Sounds great to me.  If we can't do this on gcc.gnu.org (I don't know
-- I guess we should start by talking to Gerald), we can also set up
our own site.

Sometimes I think we should set up some kind of "freejava.org" as a
kind of clearinghouse for this stuff.  The last few months I've been
really into the idea of cooperation in the free Java world... I see
Classpath as a big success and I'm very interested in expanding the
scope of cooperation.

We can share code (the verifier I hope), and also APIs (I'd like to
see the BC-ABI turn into the standard pluggable JIT interface).  But
more importantly I think we can share some marketing, it seems to be
the case that the more we cooperate, the more "real" the whole Free
Java effort appears.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]