You are not logged in. Login Now
 0-24   25-49   50-74   54-78   79-103   104-113     
 
Author Message
25 new of 113 responses total.
twenex
response 79 of 113: Mark Unseen   Mar 13 20:58 UTC 2006

I still haven't got a satisfactory answer to the question: "why should Grex
(or anyone) bother with Java, especially if they've no need or desire to
support www applications?"
spooked
response 80 of 113: Mark Unseen   Mar 13 21:02 UTC 2006

Anyone who has to resort to, nevertheless start with, abusive language in 
an attempt to convey an intellgent opinion would suggest their lack of 
credibility.  I stopped reading shortly after starting that post.  Bad 
language is often a sign of (1) bitterness, (2) ignorance, or (3) both.

twenex
response 81 of 113: Mark Unseen   Mar 13 21:30 UTC 2006

I fail to see the "abusive language" in #79. Sounds more like you're covering
up the fact that the only reason you've latched on to Java is 'cos it's
flavour of the month. In which case, you're about four or five years too late.
spooked
response 82 of 113: Mark Unseen   Mar 13 21:39 UTC 2006

<no comment> The name says it all.
twenex
response 83 of 113: Mark Unseen   Mar 13 21:43 UTC 2006

Well, I don't know where you're from, but round here there are those things
called "jokes". They're quite difficult to explain if you don't understand
them already.
khamsun
response 84 of 113: Mark Unseen   Mar 13 21:46 UTC 2006

Re #78:
well, I'm not using OpenBSD-i386 much by now, will have to boot one.But
the Java engine did work just as expected for me: Swing and popular Java
graphical or non-graphical apps, the plugin didn't crash firefox, etc.
The 1.5 version doesn't compile by now, but is on the way for FreeBSD.
Well, as for the Sun side, they are maybe not all evil,an important
issue was about the compliance test (TCK).It's ok to avoid any pile of
braces to be called Java, but on the other hand many people on the BSD
side are working hard to provide patches to make things work.

Re #79:
<I still haven't got a satisfactory answer to the question: "why should
Grex(or anyone) bother with Java, especially if they've no need or
desire to support www applications?">

exactly my question too.

Re #80:
(2)ignorance:

indeed: some Java specialist didn't seem to know that OpenBSD has a
native JVM, with bells and whistles, and Duke waving hands, and surfing
the waves...
spooked
response 85 of 113: Mark Unseen   Mar 14 09:36 UTC 2006

I would not use a hack.

And, I can guarantee it does not work as I would expect a fully-compliant 
JVM to work, even without looking at it.

khamsun
response 86 of 113: Mark Unseen   Mar 16 08:58 UTC 2006

A screenshot of an OpenBSD-3.8-i386, running few java apps:
http://www.abravo.org/misc/obsd_snapshot.jpg

a Mozilla connected to Freenet showing the environment: OS=openbsd38
JVM=SUN, HotSpot, version 1.4.2.It says it: vendor=SUN, it's the SUN
code build locally for me only, because licensing...
below, another Mozilla window showing the Sun Java test page, with Duke
dancing.The other apps running: NetBeans-4.1, the JAP anonymizer, the
Java2D demo (again: dancing Duke), bottom left: Jedit, very left:
Arachnopilia html editor, top: Jftp, plus a couple other not visible...

For development, you can run too Ant, Eclipse, etc.
----------

the Java story is a mixture of politic and technical issues.
SUN recognizes a JVM when it passes the compliance suite, TCK (former
JCK).Otherwise binaries are not redistribuable.
The problem is to submit a native JVM (like the OpenBSD one).
SUN is changing its licensing schemes every couple years.
Up to 2005, FreeBSD (and for a shorter period of time NetBSD) were
licensees, under the "scholarship" cheaper agreement.The patchset of the
FreeBSD people, which does work for Net and Open, applied to the Java
source (SCSL), the use of linux javac for bootstrap and the Lesstif
headers, did build a JVM/JRE/JDK that SUN did aknowledge.That was the
case for 1.1, 1.2, 1.3.
Binaries were distributable as genuine Java.
Then, SUN told FreeBSD they were revoking the license,unilateraly, in
the turmoil of their legal revamping.So not on a technical (software)
ground.
Ok, the current state of things is that you can freely ($0) register as
individual member in the JCP (the "community" project) and download the
TCK suite and summit for compliance approval.BUT the license you get is
nominative, ie. only for you (you share alone with yourself...)
To get the right to publish binary kits you must purchase $2000 or $5000
membership (non-profit or commercial).Kind of getting like "OEM".Still
SUN holds the right to allow or revoke the compliance label anytime.
Well, *-BSD are not Microsoft...

Practically: is you are a webhoster, a business, and will run OpenBSD:
--> you can't, for instance, run Jakarta/Tomcat on all you boxes, by
installing the same binary (JVM) on all of them.Instead you must build
Java locally on every box...
--> you can't expect official Java support

So, maybe SUN wants to avoid BSD getting in a market where Linux has
already got to outsold Solaris.
If SUN has nothing to fear they can well ease the TCK access and
compliance process to the BSD folk, without losing on the technical side
(software consistency)






janc
response 87 of 113: Mark Unseen   Mar 18 15:32 UTC 2006

Cross says OpenBSD lacks recognition in the eye of "those in a position
to make a Java port".  That's certainly true.  My point however, is that
it is a problem that such people exist.  Who are "those in a position to
make a Perl port?"  "Those in a position to make a GCC Port?"  Firefox?
 Apache?  Anybody, that's who.  There's no select club whose recognition
you have to earn to get a port of these pacages.   Java will get there,
I'm sure.  But it's a limitation on the universal applicability of the
language.
cross
response 88 of 113: Mark Unseen   Mar 18 16:12 UTC 2006

There's a difference.  Those other packages are `pure open source.'  Java's
licensing structure is, as Antonio points out, much more complex.  Those in
a position to do an OpenBSD port are those who are so licensed by Sun.
mcnally
response 89 of 113: Mark Unseen   Mar 18 19:30 UTC 2006

 re #88:  And that difference is exactly the problem Jan's pointing to.
spooked
response 90 of 113: Mark Unseen   Mar 18 23:42 UTC 2006

I think we all agree OpenBSD is not a mainstream development environment.


cross
response 91 of 113: Mark Unseen   Mar 19 05:19 UTC 2006

Oh, I misread.  I thought he was saying quite the opposite.
khamsun
response 92 of 113: Mark Unseen   Apr 15 15:25 UTC 2006

great news about the Java and BSD stuff:
http://www.freebsdfoundation.org/press/20060405-PRrelease.shtml

since 5th april 2006 and a new agreement between the FreeBSD Foundation
and Sun, Java 1.5 is officially available as binary tarball (jre &
jdk/sdk). Which means the maturity of the port on FreeBSD (x86) was good
enough to get the Sun technical blessing.The rest was political/legal
stuff.In short it's fully Java  for FreeBSD. So, on the others main
BSDs, Net and Open, only the second aspect (political) is still not
solved. (Java builds uses all the same FreeBSD patchset + minor system
dependent diffs)
cross
response 93 of 113: Mark Unseen   Apr 15 16:53 UTC 2006

I'd say that's an excellent reason to switch to FreeBSD instead of kicking
around with clunky old OpenBSD.
nharmon
response 94 of 113: Mark Unseen   Apr 15 18:24 UTC 2006

I would just like to say that I have been so impressed with FreeBSD 
that I've begun using it at work. It will be replacing our LAMP-based 
intranet system, and our Linux-based internet proxy.

These are the things I've been most impressed with:

1) Directory heirarchy. This is it folks. The all software that isn't 
part of the base OS is in /usr/local. I love it. It makes things just 
so much easier then wondering "is apache 
in /var/www, /usr/www, /srv/www, /usr/local/www, or /home/www?"

2) Ports. Ports is about as easy to use as Debian's apt, and a whole 
lost easier than SuSE's YaST.

3) Performance. Even on slower systems, FreeBSD runs faaaast.
twenex
response 95 of 113: Mark Unseen   Apr 15 21:10 UTC 2006

I STILL don't know why Grex needs Java. isn't Java only useful in browsers?

Re: #94. Gentoo Linux addresses all your concerns there, except (1).

Interesting that you say "ports are easir to use than SuSE's YaST." Isn't YaST
supposed to be the yardstick for Linux desktop software installation
usability?
mcnally
response 96 of 113: Mark Unseen   Apr 15 21:27 UTC 2006

 re #95:
 >  I STILL don't know why Grex needs Java. isn't Java only
 >  useful in browsers?

 In a word: no.  In several words: no, no, no, no, NO.
 Java isn't restricted to web applets any more than perl
 is only useful for writing back-end web-server scripts.

cross
response 97 of 113: Mark Unseen   Apr 15 21:44 UTC 2006

I think that Java on grex would be interesting, but I don't go as far as Mic
in my accolades for it as a language.
spooked
response 98 of 113: Mark Unseen   Apr 16 01:12 UTC 2006

That's probably because you don't have as much exposure to using it, Dan.  
Look, no language is the bees-end for every application.  We are building 
a very complex Geo-spatial mapping application currently.  Among the 
languages we use (for different purposes in the application) are:

- Java (core business logic, used extensively within all 3 MVC tiers 
including querying/updating to Oracle 10g database's 
tables/views/synonyms/indexes (incl. geospatial indexes)/sequences/etc)
- PL/SQL (for stored procedures including network tracing of Australia's 
major telecommunication network infrastructure interfacing for 
engineering complications with proposed powerline networks - from power 
companies, rail companies, etc)
- Crystal suite (for complex/flexible reporting)
- Javascript (*gasp* for those few client-side nicities people just can't 
seem to live wihout)

In any non-trivial application of any considerable size, you will have 
to use a combination of different languages, tools, and people skill 
resources - otherwise you will never finish the project in a timely 
fashion and reinvent the world in a language that is best used for 
other purposes.  It not only makes working in IT exciting, but also 
ensures those who are flexible and quick learners will always be in 
very high demand.


nharmon
response 99 of 113: Mark Unseen   Apr 16 02:52 UTC 2006

I need some .NET libraries installed...
khamsun
response 100 of 113: Mark Unseen   Apr 16 06:08 UTC 2006

(well, me think latest SunOS-4.1.x what good enough for Grex.Powered by
some ss20 quad hypersparc or some sparcserver 1000 8x cpu for instance.)
twenex
response 101 of 113: Mark Unseen   Apr 16 15:45 UTC 2006

OMG! We forgot APL and PL/1!

;-)
spooked
response 102 of 113: Mark Unseen   Apr 16 17:55 UTC 2006

See http://www.citidel.org/?op=getobj&identifier=oai:ACMDL:articles.808118 
- nice high-level, flexible language/s
cross
response 103 of 113: Mark Unseen   Apr 16 18:02 UTC 2006

Regarding #98; Actally, it's because I probably have *more* exposure to it and
a lot of other languages.  There are certain things in Java that are just poor
design decisions.  Among them:

1) (At least initially) lack of a well-designed standard library.
   Tell me why each new release of Java seems to reinvent basic libraries?  We
   went from AWT to Swing.  From no threads to coroutine based threads with
   monitors for concurrency.  From one set of collections to the other.
2) Why aren't `primitive' types objects?  Please don't tell me efficiency.
   But this means that you can't have a generic, object based container
   library that contains int's.  You have to wrap them in Integers.  This also
   means that arrays aren't objects; they're primitive types.  C++ made this
   mistake, and now we have to pay for it with templates.  It's interesting to
   note that smalltalk had everything as an object, and ran with good
   performance and much smaller hardware than Java ever ran on.  So it's not
   efficiency.
3) Speaking of efficiency....  Why go with a stack based VM?  That sort
   of thing just doesn't map well onto actual hardware, which is usually based
   on register machine models.  Why not go with something like the Dis virtual
   machine used in the Inferno system?  Based on a memory to memory model, the
   VM maps well onto current instruction sets.  Thus, it's easy to write a JIT
   compiler for it which gives really pretty good performance.  With Java, the
   compiler is simple (since the ``machine code'' is very similar to the ADT's
   the compiler spits out - one of the nicities of the stack based VM), but
   the JIT is rather more complex.  This makes Java code have a high startup
   cost, which is rather annoying.  I'd rather Josling et al had taken the
   middle ground that Phil and Rob did with Inferno.
4) The concurrency model is based on the 1960's style of coroutines and
   explicit mutexes.  Why not make it based on CSP?  Come on, we could have
   moved boldly into the 1980's!
5) Java has a high start up and entry cost; it discourages casual programs.
   It is difficult to write a one-off program in Java whereas it's almost
   trivial in a higher level language like Python or Ruby.

This is just a sampling of the things I think Java is imperfect on; I could go
on.  Like I said, I think Java on grex would be interesting, but I don't think
it's a great language.  Better than most of its predecessors, it failed to
learn some essential lessons from some of the better ones, and the result has
been an often inconsistent and a moving target.  The fact that they just added
a form of ``for (item in someset) { ... }'' syntax in Java 1.5 tells me they
didn't quite think it through the first time, even though a lot of other
languages have been doing similar things for a *long* time (e.g., smalltalk
and awk, which both predate Java and have similar mechanisms.  While awk
doesn't have the semantic expressiveness of the type system that Java does,
smalltalk certainly does).

Mic, please don't insult me by saying it's just because I don't know enough
about it; I've implemented enough things of sufficiently large scale that I
have some idea of what I'm talking about when it comes to language design.
 0-24   25-49   50-74   54-78   79-103   104-113     
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss