|
|
| Author |
Message |
| 25 new of 113 responses total. |
twenex
|
|
response 79 of 113:
|
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:
|
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:
|
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:
|
Mar 13 21:39 UTC 2006 |
<no comment> The name says it all.
|
twenex
|
|
response 83 of 113:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
Mar 18 19:30 UTC 2006 |
re #88: And that difference is exactly the problem Jan's pointing to.
|
spooked
|
|
response 90 of 113:
|
Mar 18 23:42 UTC 2006 |
I think we all agree OpenBSD is not a mainstream development environment.
|
cross
|
|
response 91 of 113:
|
Mar 19 05:19 UTC 2006 |
Oh, I misread. I thought he was saying quite the opposite.
|
khamsun
|
|
response 92 of 113:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
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:
|
Apr 16 02:52 UTC 2006 |
I need some .NET libraries installed...
|
khamsun
|
|
response 100 of 113:
|
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:
|
Apr 16 15:45 UTC 2006 |
OMG! We forgot APL and PL/1!
;-)
|
spooked
|
|
response 102 of 113:
|
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:
|
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.
|