response 54 of 113:

Feb 28 01:18 UTC 2006

I think #52 is saying that java is resource intensive and therefore not
suitable for a slow crowded system like grex.

response 56 of 113:

Feb 28 01:35 UTC 2006

 #52 appears to confuse Java, the programming language, with Java applets,
 executable code collections which are most often run embedded in a web
 browser.  Java has plenty of other uses, and is, in fact, a useful
 technology, which is why I find it odd that mic can't put together a
 more convincing argument in its favor.

response 58 of 113:

Feb 28 06:03 UTC 2006

I think twenex's name is dumb.

After all, planes don't actually FLY at the airports!

They just land there and hang out.  :(

response 60 of 113:

Feb 28 09:28 UTC 2006

Java, which I have been associated with professionally for nearly a 
decade, continues to grow in popularity.  You can earn really large 
amounts of money if you have advanced Java skills - particularly scarce 
at the moment, in terms of talented people versus projects in industry, 
are talented people in the J2EE arena.  The supply of work is vastly 
outnumbering the talented/skilled pool set.  Java is massive - from smart 
portable devices to inter-enterprise applications - Java is thriving.  
One of the major resources I believe where Grex can benefit from offering 
Java is attracting and assisting budding Java developers (compared to unix 
shell script and C programming skills, the market is 10-fold+ after Java 
skills).  Some of the coolest web applications can be built for Grex using 
Java technologies such as JSP, JDBC, and existing opensource codebases - 
abundant! - out there.  The level of coolness and time to build such 
applications in Java vastly surpasses anything which can be built in C, 
Perl, Python, Ruby - I have worked with them all.  In some of the coolest 
operating systems, such as Solaris 10, you can easily constrain 
users/processes/applications to a size of the resource pool (such as 
RAM).  I think I have responded, in brief, to everyones major points.

response 62 of 113:

Feb 28 17:05 UTC 2006

The greatest advantage that I can think of to installing Java on grex is
that tools available in Java make unit testing possible for any coding
projects that are considered for system-wide deployment on Grex.

Unit testing is a way of programming which, if done properly, can
identify and thereby allow the complete elimination of buggy code prior
to deployment.  If Grex installs a Java framework to support unit
testing, it may make it much easier for people to contribute tools and
applications in a way that the staff will feel comfortable adding
capabilities to the system without risking a lot of follow-up work
tracking down and fixing bugs.

response 64 of 113:

Feb 28 21:24 UTC 2006

I tried to address Unit Testing with grexsoft, but no one but me was ever
interested.  I take exception to Mic's assertion that Java is more efficient
to program in (as opposed to machine efficiency) than, say, Python or Ruby.
I do note that, according to a cursory search on Freshmeat, the union of
Ruby, Python, and Perl projects has the about a thousand more projects in it
than the set of Java related projects (at around 4600 projects or so; that's
about the same as the number of C++ projects, and probably half the number
of C projects).

But that's neither here nor there.  As a system, we should be trying to
get a current, modern JRE and development environment running on grex.
That means an operating system with developers more likely to be more
responsive than, ``you're on your own'' or ``we don't do that here, and
neither should you.''

response 66 of 113:

Mar 1 09:11 UTC 2006

Yay, finally some clearer thinking from folk.

Ruby is a VERY promising language, Dan, especially Ruby on Rails 
framework... BUT, it seriously cannot compete with Java now or in the next 
decade.

response 68 of 113:

Mar 1 21:23 UTC 2006

No problemo.

response 70 of 113:

Mar 2 21:51 UTC 2006

(regarding #68; Well, except that we are agreed that grex needs to move to
a better supported OS!)

Regarding #69; Kaffe is also no where near the JDK in terms of
sophistification.  OpenBSD really doesn't support a Java that's worthy of the
title.

response 72 of 113:

Mar 3 13:58 UTC 2006

What can I say?  It was all those years living on the lower east side.  :-)

response 74 of 113:

Mar 11 21:01 UTC 2006

I have done quite a bit of work on the backtalk/sage interface this
week.  Mostly I've been working on the configuration tools, which are
fairly hard to design, since I'm going for massive configurability. 
Still have a ways to go before I can demo anything though.

response 76 of 113:

Mar 12 14:30 UTC 2006

I think the lack of Java on OpenBSD is, as Mic said, more a reflection of the
status (or lack thereof) of OpenBSD in the eyes of those in a position to make
a Java port.  But it also stems from some technical failings of OpenBSD, like
the lack of a real, kernel-level POSIX compliant threads implementation. 
Yeah, there's a library that sort of does the right thing by turning
everything into non-blocking calls and trying to multiplex, but the entire
system can still freeze on some system calls.

Java is quite complex, and porting it to a new platform, particularly one only
subtly different from another that's well supported, is tricky.

response 78 of 113:

Mar 13 20:50 UTC 2006

Does it *all* work, or just parts?  Usually, that's the issue.  For instance,
threads and swing may not work.  Also, Java 1.5 really is much better....

I also think it's UNfair to say that it's all licensing on the Sun side.