headers
Newsbyte | 1 Oct 2004 10:34

JVM

"We must continue to only use 1.4 features, because it's hard enough to
get GCJ/Kaffe/Classpath working without having to track a constantly
moving target..."

That's rather silly. You can't keep using 1.4 indefinately! I mean, what?
Are you still going to use 1.4 by the time they are at 10.5 ? ;)

As far as the features are the same, there is no problem, and when they are
faster/better we SHOULD use them. And classpath, ah well, a smart coder like
you surely will find something that can deal with that in an automated way
:-)

Seriously, I can understand you don't feel like having to change to every
new subversion, like, say, as with freenet ;-p, but this is a major new
build, which will probably last for some considerable time (just as the
1.4). It would be rather foolish to ignore it, especially since there have
been some problems with 1.4(.2). And besides, immer more people will use it,
so saying they have to revert to an old 1.4 build is no solution anyway.

As for specific features...well, you're the coder. If we don't need them or
can't use them, I guess you can leave it like it is. But I would argue that
if they do bring additional benefits, one should use them accordingly.
Permalink | Reply | 5 comments |
headers
Mika Hirvonen | 1 Oct 2004 11:41

Re: JVM

Newsbyte wrote:

> As far as the features are the same, there is no problem, and when they are
> faster/better we SHOULD use them. And classpath, ah well, a smart coder like
> you surely will find something that can deal with that in an automated way
> :-)

Not classpath the environment variable, this classpath: 
http://www.gnu.org/software/classpath/classpath.html

> Seriously, I can understand you don't feel like having to change to every
> new subversion, like, say, as with freenet ;-p, but this is a major new
> build, which will probably last for some considerable time (just as the
> 1.4). It would be rather foolish to ignore it, especially since there have
> been some problems with 1.4(.2). And besides, immer more people will use it,
> so saying they have to revert to an old 1.4 build is no solution anyway.
> 
> As for specific features...well, you're the coder. If we don't need them or
> can't use them, I guess you can leave it like it is. But I would argue that
> if they do bring additional benefits, one should use them accordingly.

Sure, there are many places in the codebase where new features like 
enums would be handy.

The trouble is that Free (as in speech) JVMs don't even properly support 
some of the features we use currently (like NIO), so using more features 
that they don't support would bring the project further away from those 
JVMs.

And we want to be able to run Freenet on Kaffe/GCJ/Classpath, because
(Continue reading)

Permalink | Reply | 4 comments |
headers
Robert 'd-ArkAngel' Laverick | 1 Oct 2004 11:59

Re: JVM

While I agree with the arguments for support on non SUN JVM's, I don't see
why that should be relevant to which version of the sun JVM we reccomened.
 We don't Have to use the new language features, and recomending a newer
version of suns JVM should be a step forward.  As long as we're not
breaking code that currently works with sun's JVM just to support a
specific GPL JVM then I don't see a problem.

I'm already running with the new sun JVM because it's the only one from
sun that's released in x86_64, and that gives me significant perfomance
advantages over 1.4.  It'd be like a windows developer recommending
windows 2000 but still having his code support windows 98.

On Fri, October 1, 2004 10:41 am, Mika Hirvonen said:
>
> Sure, there are many places in the codebase where new features like
> enums would be handy.
>
> The trouble is that Free (as in speech) JVMs don't even properly support
> some of the features we use currently (like NIO), so using more features
> that they don't support would bring the project further away from those
> JVMs.
>
> And we want to be able to run Freenet on Kaffe/GCJ/Classpath, because
> not only is it easier to get JVM bugs fixed with free alternatives, some
> of their libraries are faster than Sun's. Making Freenet GCJ-compatible
> (or GCJ Freenet-compatible) would mean that we would be able to compile
> native versions of Freenet.
>
> Also, from the political point of view, if Freenet worked on free JVMs,
> it could be included in various distributions that can't bundle Sun's
(Continue reading)

Permalink | Reply | 3 comments |
headers
dave | 1 Oct 2004 11:55

Re: JVM

> I'm already running with the new sun JVM because it's the only one from
> sun that's released in x86_64, and that gives me significant perfomance
> advantages over 1.4.  It'd be like a windows developer recommending
> windows 2000 but still having his code support windows 98.

IMO it's more like a developer recommending Windows 98 because he knows it
works there, and he's less convinced that it works on Windws 2000.  Even
though he has evidence that Windows 2000 is compatible with Windows 98,
and even though he has reports that the software runs fine on Windows
2000.

No, I don't understand why we're *recommending* an old sun jvm either.
Permalink | Reply | 0 comments |
headers
Mika Hirvonen | 1 Oct 2004 11:58

Re: JVM

Robert 'd-ArkAngel' Laverick wrote:

> While I agree with the arguments for support on non SUN JVM's, I don't see
> why that should be relevant to which version of the sun JVM we reccomened.
>  We don't Have to use the new language features, and recomending a newer
> version of suns JVM should be a step forward.  As long as we're not
> breaking code that currently works with sun's JVM just to support a
> specific GPL JVM then I don't see a problem.

Agreed. I'm currently using 1.5 myself.

--

-- 
   Mika Hirvonen <hirvox@...>
   http://nightwatch.mine.nu/freenet/
Permalink | Reply | 0 comments |
headers
Newsbyte | 1 Oct 2004 12:26

JVM

"The trouble is that Free (as in speech) JVMs don't even properly support
some of the features we use currently (like NIO), so using more features
that they don't support would bring the project further away from those
JVMs."

So, ermm...basically, we should recommend an obsolete SUN JVM because the
free JVMs suck? I fail to see the logic.

I'm sorry, I'm of the opinion of Linus in this case. Once there was a
discussion between him and Richard about the use of a cvs-kinda-thingy; R
thought he should use a free/open source cvs system, while linus prefered a
proprietary system, because it was technological superior. His reaction was:
"when they make it as good as that other system, then I'll switch".

Now, I agree with some of your points, I'm inclined towards the free (beer
and speech) ideology too, and getting a larger userbase and all that; very
true. But when push comes to shove, we should go with the the JVM that is
technologically superior (and is, after all, still pretty free concerning
its use). Your points have some validity, but ultimately, it's those free
JVMs problems, not ours. We can't wait untill they figger out how to deal
with NIO and all the rest. I mean, it's all well that they are free, but if
they suck too much to be used by Freenet, the point is rather moot.
Permalink | Reply | 4 comments |
headers
Ed Tomlinson | 1 Oct 2004 12:38

Re: JVM

Hi,

One other point.  The compiler is not the JVM.  We could recommend using
the jikes compiler and the 1.5 JVM.  This way we could limit the use of new
features but gain performance benefits from the new JVM...

Ed

On Friday 01 October 2004 06:26, Newsbyte wrote:
> "The trouble is that Free (as in speech) JVMs don't even properly support
> some of the features we use currently (like NIO), so using more features
> that they don't support would bring the project further away from those
> JVMs."
> 
> So, ermm...basically, we should recommend an obsolete SUN JVM because the
> free JVMs suck? I fail to see the logic.
> 
> I'm sorry, I'm of the opinion of Linus in this case. Once there was a
> discussion between him and Richard about the use of a cvs-kinda-thingy; R
> thought he should use a free/open source cvs system, while linus prefered a
> proprietary system, because it was technological superior. His reaction was:
> "when they make it as good as that other system, then I'll switch".
> 
> Now, I agree with some of your points, I'm inclined towards the free (beer
> and speech) ideology too, and getting a larger userbase and all that; very
> true. But when push comes to shove, we should go with the the JVM that is
> technologically superior (and is, after all, still pretty free concerning
> its use). Your points have some validity, but ultimately, it's those free
> JVMs problems, not ours. We can't wait untill they figger out how to deal
> with NIO and all the rest. I mean, it's all well that they are free, but if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mika Hirvonen | 1 Oct 2004 12:47

Re: JVM

Newsbyte wrote:

> "The trouble is that Free (as in speech) JVMs don't even properly support
> some of the features we use currently (like NIO), so using more features
> that they don't support would bring the project further away from those
> JVMs."
> 
> So, ermm...basically, we should recommend an obsolete SUN JVM because the
> free JVMs suck? I fail to see the logic.

1.5 is more than just a JVM. The JVM itself is okay and should be used 
in favor of 1.4.x. IMHO the source should be kept as portable as 
possible so we can switch if they do get over the pressing problems.

> Now, I agree with some of your points, I'm inclined towards the free (beer
> and speech) ideology too, and getting a larger userbase and all that; very
> true. But when push comes to shove, we should go with the the JVM that is
> technologically superior (and is, after all, still pretty free concerning
> its use). Your points have some validity, but ultimately, it's those free
> JVMs problems, not ours. We can't wait untill they figger out how to deal
> with NIO and all the rest. I mean, it's all well that they are free, but if
> they suck too much to be used by Freenet, the point is rather moot.

I'll have to agree with you here. IMHO, a theory (or an ideology) is 
useless if it doesn't offer any practical benefits. But 
Kaffe/GCJ/Classpath is both superior in some areas and inferior in other 
areas.

--

-- 
   Mika Hirvonen <hirvox@...>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Newsbyte | 1 Oct 2004 13:02

JVM

"One other point.  The compiler is not the JVM.  We could recommend using
the jikes compiler and the 1.5 JVM.  This way we could limit the use of new
features but gain performance benefits from the new JVM..."

Yes, well, I'm not sure I'm of the opinion we shouldn't use new features, if
they are beneficial for freenet.

Let's face it: it's somehow pretty illogical to refuse to use features of a
JVM that makes your program work better or more efficient, with the
reasoning that other JVMs aren't there yet. As Mika said, NIO isn't handled
well by the free JVMs, so we're already doing it anyway. It's for them to
catch up, which, if the claim "it is easier to get JVM bugs fixed with free
alternatives" is right, should pose no problems. But our pace of development
can't be constraint by the slowest (in devl features) JVM, free or not. If
we had done that, we still wouldn't have NIO.

Can anyone seriously suggest we shouldn't go for an
efficiency/speed/whatever - boost for freenet, because other JVMs haven't
catched up yet?
Permalink | Reply | 3 comments |
headers
Mika Hirvonen | 1 Oct 2004 13:37

Re: JVM

Newsbyte wrote:

> "One other point.  The compiler is not the JVM.  We could recommend using
> the jikes compiler and the 1.5 JVM.  This way we could limit the use of new
> features but gain performance benefits from the new JVM..."
> 
> Yes, well, I'm not sure I'm of the opinion we shouldn't use new features, if
> they are beneficial for freenet.

An overview of the new features is at:
http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/
and
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

> Let's face it: it's somehow pretty illogical to refuse to use features of a
> JVM that makes your program work better or more efficient, with the
> reasoning that other JVMs aren't there yet. As Mika said, NIO isn't handled

Most of them are language enhancements that make some things easier to 
do that were cumbersome before.

Yes, those features would be benefical to Freenet. Yes, they would make 
the code more streamlined and elegant. But would they make the node 
faster or more efficient? Probably not by much.

As for the java.util.concurrent package, we use a similar free package 
already.

> Can anyone seriously suggest we shouldn't go for an
> efficiency/speed/whatever - boost for freenet, because other JVMs haven't
(Continue reading)

Permalink | Reply | 0 comments |

Gmane