Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread Nathan Meyers

Whoa... how did this discussion suddenly become religious?

I daresay the readership of this group is here because they see a future
for Java beyond its current problems. As a fan of both Java and Perl, I
have absolutely no need to resolve the which-is-faster-and-better
question once and for all; I use the tool that best solves the problem.
I decided to stop waiting for the perfect tool/environment in favor of
squeezing off a few more projects before I reach retirement age a few
decades from now.

Nathan



John Goerzen wrote:
> 
> On Tue, Feb 16, 1999 at 08:03:26PM -0500, Daniel W. Dulitz x108 wrote:
> 
> > John, you wonder about the technical advantages of Java.  Java is all
> > about balancing easy to write and easy to read code against runtime
> > performance.  Think C versus assembly language.  And the real question
> > is, "Is the runtime performance of Java adequate?"  For all but the
> > tiniest web servers, the answer is yes.  Is servlet development time
> 
> This is not really the point.  The point is that for a heavily-loaded
> server, even a small difference in performance can make a tremendous
> difference in the system -- possibly the difference between running well and
> not running at all.



Re: JavaLinux for servlets

1999-02-17 Thread John Goerzen

On Tue, Feb 16, 1999 at 06:10:02PM -0700, Robert Ritchy wrote:

> In addition to the above - portability.  I just finished a complete a servlet
> solution for a BIG company on my dinky pentium 75 linux laptop (apache/jrun).  The
> installation on their site (Solaris/NES/JRun Pro) was MINIMAL with no
> environment/configuration changes except for the addition of the path to the new
> servlet.  I just uploaded the classes and html templates and updated the jrun
> configuration file.

For servers, I'm unsusre that portability is a big win, or even much better,
with Java than Perl.  Perl programs run all over, and well-written C
programs do as well, although probably there would need to be a lot of
changes.

> 
> >
> > On Tue, 16 Feb 1999, John Goerzen wrote:
> >
> > > On Tue, Feb 16, 1999 at 04:34:03PM -0800, Kevin Hester wrote:
> > >
> > > But what techincal advantage do they really give?  Java is slower, uses more
> > > system resources, etc.
> > >
> > > John
> > >
> > >

Content-Description: Card for Robert Ritchy



Re: JavaLinux for servlets, who to make templates?

1999-02-17 Thread Marcel Ruff

Hi

you wrote about servlets and html-templates.
What possibilities are there to make html-templates
and where is there a good parser to build the final html file
from the template?

thanks, Marcel




--
Marcel Ruff
[EMAIL PROTECTED]
http://www.lake.de/home/lake/swand/





Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread Chris Huebsch

Hello,

let me contribute a word or two to this discussion...

John Goerzen wrote:
> 
> This is not really the point.  The point is that for a heavily-loaded
> server, even a small difference in performance can make a tremendous
> difference in the system -- possibly the difference between running well and
> not running at all.

AFAIK unix doesn't support real threads. For new requests a new instance
of the CGI is created with fork() or something like that? Now imagine a
server with a load around 99%. 

The first is a "non-java-at-all" Server. It has to create a new process
when a request arives. Where? The system is almost at the limit? It is
likely that it starts paging and if paging starts performance will go
down very fast.

The second server uses servelets and a thread-pool. When a request
arrives a thread is taken from the pool, executes the request and sent
back to the pool. There are no processes to create. Memory is already
allocated (of course - paging may be done here too). When the Server
runs a while then all Classes are native-compiled.

> I do disagree that Java is more maintainable than Perl in general.  If you
> know Perl, it is quite easy to read and maintain.  The regexp support makes
> it far easier to code and maintain anything that parses things that are even
> vaguely complex.

Yes. RegExps are really missing in the java-core. But there are many
pure-java extensions available.

> I do not, and have never, reccommended PHP3 for anything "serious", for just
> these issues, and others.  But mod_perl and FastCGI are quite good for CGI.

Database-Access with php or perl may be simple with simple problems. But
when the problem gets more complex the problems increase exponentially.
For instance you change your database from oracle to informix. With php
you may change all your pages and replace oracle_db_XXX() to
informix_db_YYY(). In java you write a factory which creates the
SQL-Statements and only change the factory. The remaining parts of your
application/applet/servlet remain untouched

> No, I've seen Java programs, and even a "serious" applet or two.  The point
> is that this is not an acceptable or useful paradigm in my opinion.  The
> fact that the language used is Java is really irrelevant.

Java is not just a language! It is an very large API and a Virtual
Machine too.
And one usefull use of Applets: I wouldn't do my online-banking with
ActiveAEKS or just SSL. A-X wouldn't run on a Sparc ;)

> If one really wants this sort of thing, embedded X may be a better solution,
> but it has lots of problems, too.  I don't think it's a good solution either
> (except perhaps for corporate LANs.)

There are some problems which require not much data-transfer but a lot
of graphical work. I cannot imagine transferring every single screen via
X-protocol. (Embedded X is a X-Server inside the browser - isn't it?)
This would almost be like Microsofts "terminal server". (Which needs
huge amounts of main-memory for each clinent)

> You're clouding the issue.  The point is that HTML itself is not adequate in
> the case you're describing.  In fact, the whole Web idea is not adequate
> here, and it was never designed to be.

Of course it wasn't. But applets seem to be a good solution to extend
HTML to be more "active". (And I do not speak of scrolling texts or
animated images!)

> I have never disagreed that a Java-based GUI application (note, not applet)
> as a client would be good, and in fact, in the message to which you are
> replying, you snipped the part where I said so.

As already written - why to risk serious trouble by mixing lots of
different technologies when you can use one? (If you really need peak
performance you could use JNI with ANSI-C on the serverside)

> I wish people would stop comparing a current Java idea with an outdated CGI
> one.  If you want to compare it to CGI, please do us the favor and compare
> it to current CGI ideas.

And I wish people would stop comparing a current CGI idea with an
outdated Java one ;)
Java was designed with JITs in mind. Why would the bytecode assume a
stack-architecture (which is simmilar to intermediate-code of "normal"
compilers) if not to compile the last stage?

regards


Chris
-- 
public class chu extends ChrisHübsch implements TUChemnitz {
  String  email= "mailto:[EMAIL PROTECTED]";
  String  SMSMail  = "mailto:[EMAIL PROTECTED]?Subject=SMS: info";
  URL homepage = new URL("http://www.tu-chemnitz.de/~chu/");
  Talktalkto   = new Talk("[EMAIL PROTECTED]");
  Integer ePlus= new Integer(4628555);
}



question from a java novice

1999-02-17 Thread Sohail Zafar




Can some body tell me what is the difference 
between pointers in C++ and handles in java.
Regards
Sohail


Re: JavaLinux for servlets

1999-02-17 Thread Steve Byrne

John Goerzen writes:
 > On Tue, Feb 16, 1999 at 04:34:03PM -0800, Kevin Hester wrote:
 > 
 > > 
 > > > I would certainly not use Java for CGI.  libapache-mod-perl, FastCGI, etc.
 > > if necessary.
 > > 
 > > I'd definitely encourage anyone to use servlets with wild abandon.  So easy
 > > and clean - I haven't had to write CGI cruft in over a year.  In exchange
 > > for servlets I have a logical/maintainable tree of server side classes.
 > 
 > But what techincal advantage do they really give?  Java is slower, uses more
 > system resources, etc.

John, if you don't like Java, can you please tell us why you feel it's
necessary to clog this mailing list with your anti-Java sentiments?  I don't
think it's being constructive. 

Steve



graphics printing in printing

1999-02-17 Thread Steve Byrne

C.V. Rajagopal writes:
 > i have been experimenting with graphics printing in java under linux.
 > 
 > when i press the print button in the print dialog box it gives an error
 > message like the following
 > 
 > "Could not execute print commands[Ljava.lang.String:080a5470".
 > 
 > but i could print it to a file
 > 
 > please help
 > 
 > linux 2.0.32
 > java jdk1.1.5 

Why aren't you running JDK 1.1.7?

 > 
 > Rajagopal
 > 
 > River Valley Technologies
 > STPT, India
 > 
 > 



Re: JDK 1.2 Snapshots???

1999-02-17 Thread Steve Byrne

Nathan Meyers writes:
 > Tony Pujals wrote:
 > 
 > > Ouch!  ;-)
 > > 
 > > (But I'd still like to know what happened to the web site information?)
 > > 
 > > Tony
 > 
 > Fair enough desire. Those of us who've been on the list awhile have endured
 > frequent storms of "where is JDK1.2?" activity, and perhaps our fuses have
 > become a little short. We're all anxious for the bits; a perusal of the archives
 > will turn up those discussions and even some progress reports -- hence my
 > impatience with someone who admitted not doing the homework. Granted, it would
 > be nice to keep the site a bit more up-to-date -- that's also been discussed --
 > but that's not getting top priority at the moment.

I'll do something that I'm going to no doubt regret in the fullness of time:
disclose my plans ahead of time.  

My plan is to make a JDK 1.2 porting status web page that describes where we're
at with porting, which of the JCK sections we've passed, and on what
platforms.  I think it strikes a fair balance between the amount of time I need
to spend updating it, how much information is useful to people to read, and
not disclosing full details about the JCK (which I'm not legally allowed to
do).  

Please don't pester me or the list with "when will it be available" type
questions (for either JDK or my status page).  I'll make it available as soon
as I can; my time has been rather scarce lately, but I am doing what I can to
make more of it available to complete things like the status page.

Steve



Re: graphics printing in printing

1999-02-17 Thread Steve Byrne

Thomas Down writes:
 > C.V. Rajagopal wrote:
 > > i have been experimenting with graphics printing in java under linux.
 > > 
 > > when i press the print button in the print dialog box it gives an error
 > > message like the following
 > > 
 > > "Could not execute print commands[Ljava.lang.String:080a5470".
 > > 
 > > but i could print it to a file
 > 
 > Have you got the X printing library (/usr/X11R6/lib/libXp.so on my
 > machine) installed?  If not, try upgrading to the latest version of
 > XFree86.

That's not the problem.  JDK 1.1.5 tries to execute /bin/lp (I think) with
/bin/lp type arguments.  You probably don't have /bin/lp, but rather /bin/lpr
with /bin/lpr type arguments.  I think we fixed this (again) in 1.1.7 (it was
fixed in 1.1.2 or 3 -- it's one of the few places we have to tweak the .java
files during porting, since the code explicitly invokes /bin/lp with /bin/lp
type arguments).  Or, you could install /bin/lp (if it's available for Linux),
or you could make a wrapper shell script that maps the arguments to the
corresponding lpr arguments and invokes lpr and name it /bin/lp.

Steve



-prof:file option usage?

1999-02-17 Thread Joseph H. Buehler

What's the trick to getting -prof to output useful information?  I
never see any of my own classes in the output.  Maybe this is because
I am using TYA and something is not implemented?

Joe Buehler



Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread Alex Romadinoff

>AFAIK unix doesn't support real threads. For new requests a new instance
  
?
>of the CGI is created with fork() or something like that? Now imagine a
>server with a load around 99%.


Are you sure ?
What about 'clone' on Linux ?

With best wishes,
Alex Romadinoff



Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread Christopher Rowan

Wht?

Alex Romadinoff wrote:
> 
> >AFAIK unix doesn't support real threads. For new requests a new instance
>   
> ?
> >of the CGI is created with fork() or something like that? Now imagine a
> >server with a load around 99%.
> 
> Are you sure ?
> What about 'clone' on Linux ?
> 
> With best wishes,
> Alex Romadinoff



jdk1.2

1999-02-17 Thread Suddendorf Rainer


Hi there,
until recently there was an entry for jdk 1.2.
I am an enthusiastic java linux developer and hope there will be a port for
linux.
Are there any efforts? Whom can I contact?
Thanks Rainer SuddendorfMit freundlichen Gruessen / Best Regards
> Rainer Suddendorf
> 
> E-Mail: [EMAIL PROTECTED]
> 
> 



Change of e-mail account.

1999-02-17 Thread Ejaz Mohd

Hello,
I would like to change the e-mail account for java mailing list
to 
[EMAIL PROTECTED]
Please bear the trouble
Ejaz

__
Get Your Private, Free Email at http://www.hotmail.com



Re: Help me compile for Native Methods?

1999-02-17 Thread Uncle George

Gee -static to create a shared .so file ? maybe u wanna look at -shared !

> > libHelloNative.so: HelloNative.c HelloNative.h
> > gcc -c -o libHelloNative.so  \
> > -static \
> > -I/usr/java/include \
> > -I/usr/java/include/genunix \
> >  HelloNative.c
> >



RE: jdk1.2

1999-02-17 Thread Jaco Greeff

> Are there any efforts? Whom can I contact?

Aarg! One more of these and I'm going to crack! This is not
funny anymore, these people are turning the list into a spamming exercise.
(Not that I'm helping by relying, but I just had to...)

*sigh*

-- jaco greeff

The Internet Solutione-Commerce Integration
Tel: +27 (0)11 283 5684Cell: +27 (0)83 301 5005

"Linux supports the notion of a command line for the 
same reason that only children read books with only 
 pictures in them."



Re: jdk 1.1.7.1a / tya 1.2v3 performance?

1999-02-17 Thread Michael Thome

> "Joseph" == Joseph H Buehler <[EMAIL PROTECTED]> writes:
> I am trying to do some simple image processing with Java, and finding
> the performance to be not exactly stellar.  My code was originally
> written in C++ using Motif, and that version runs circles around the
> Java version.

The java.util.* classes are tuned for safety (particularly in a
multi-threaded environment) rather than performance.  Ok, maybe
"tuned" is too strong a word. ;-)

I'm on a very similar setup to yours (ppro200, RH5.1+kernel2.2.1,
jdk117, tya12v3) - not sure why my base time is significantly faster.

Your code (as written):
 TYA 1.2v3 (for J117 / Linux). Copyright (c) 1997,98,99 The TYA Team
 Contact  The TYA Team   via Albrecht Kleine  <[EMAIL PROTECTED]>
seconds: 20
iterations/second: 94545.0

Now, using a Tuned bitset which doesn't do bounds checking, an extra
static method call and a synchronize per set():
 TYA 1.2v3 (for J117 / Linux). Copyright (c) 1997,98,99 The TYA Team
 Contact  The TYA Team   via Albrecht Kleine  <[EMAIL PROTECTED]>
seconds: 7
iterations/second: 266567.0

True, we've now lost expandability, error checking and simultaneous
access, but if you don't need those facilities, you might as well not
pay for 'em.

A little experimentation shows that by far the largest factor in this
code is the synchronize in the BitSet.set() implementation.
Allegedly, HotSpot (and perhaps other vms/jits) should make syncs
significantly faster.  Meanwhile, if you really need fast java, you
should be careful choosing which classes you use off the shelf and
which you write yourself. 

Cheers,
-mik

> I wrote the following as a simple test to make sure that I do not have
> something wrong with my Java setup:

> package test;

> import java.util.*;

> class testmain
> {
> public static void main(String argv[]) {
> long start = System.currentTimeMillis();
> int iterations = 10 * 1024 * 1024;
> BitSet b = new BitSet();
> for (int i=0; i b.set(i);
> }
> long stop = System.currentTimeMillis();
> float rate = iterations * 1000 / (stop - start);
> System.out.println("seconds: " + ((stop - start) / 1000));
> System.out.println("iterations/second: " + rate);
> }
> }

> When I run this on my PPro 200 Redhat 5.1 box, I see the following:

> CLASSPATH="testmain:$CLASSPATH" java test.testmain
>  TYA 1.2v3 (for J117 / Linux). Copyright (c) 1997,98,99 The TYA Team
>  Contact  The TYA Team   via Albrecht Kleine  <[EMAIL PROTECTED]>
> seconds: 27
> iterations/second: 67851.0


-- 
Michael Thome ([EMAIL PROTECTED])



problem jdk1.2

1999-02-17 Thread Ozer Irfan

I have this message


Exception in thread "main' java.lang.NoClassDefFoundError

when I run

java test1

With javac I don't have problems

this is the program


import java.io.* ;

public class test1 {
public static void main(String args []) {

System.out.println("Hello");
}
}


Thanks



Re: question from a java novice

1999-02-17 Thread Christopher Hinds



Pointers in C\C++ can be cast to pointers of other valid types and manipulated
with various
standard library functions or just plain pointer arithmetic.
    Example C\C++:
    int  number = 12345;
    unsigned char * charNumber
= (unsigned  char*)&number;
 
    if(charNumber[0] = 0x31
)
 
charNumber[0] = 0x0A;
 
    SomeClass* clazz = new SomeClass();
    unsigned char * pCharSomeClass
= (unsigned char*)clazz;
    pCharSomeClass[0] = 0x00;
 
    memset(pCharSomeClass,0xFF,10);
   
..
    The above mischief would be impossible in Java because
    you could never cast inappropriate types to one
another. If
    the compiler doesn't catch it as an fatal error
then any good
    JVM should catch it during code verify phase of
class loading.
 
    cheers
    Chris.
 
Sohail Zafar wrote:
 Can some
body tell me what is the difference between pointers in C++ and handles
in java.RegardsSohail





Re: problem jdk1.2

1999-02-17 Thread Jason Hoffman

Your CLASSPATH environmental variable must be set to point at the root
directory containing your class files.  So, in this example, if your
current working directory was /home/Ozer, then you need to set your
CLASSPATH like this (assuming you are using the bash shell)

export CLASSPATH=$CLASSPATH:/home/Ozer

The above statement assumes you CLASSPATH has already been set to see
your "classes.zip" file distributed with the JDK.  If it has not been
set (assuming you installed the JDK in /usr/local ), then your CLASSPATH
would have to be set also include the path to classes.zip.  It would be
something like this:

export CLASSPATH=/usr/local/JDK/lib:/home/Ozer

Type in both of these lines (substituting the paths on your computer )
from the Shell prompt.  Hope this helps ( I believe it should )

Jason Hofffman ([EMAIL PROTECTED])



Ozer Irfan wrote:

> I have this message
>
> Exception in thread "main' java.lang.NoClassDefFoundError
>
> when I run
>
> java test1
>
> With javac I don't have problems
>
> this is the program
>
> import java.io.* ;
>
> public class test1 {
> public static void main(String args []) {
>
> System.out.println("Hello");
> }
> }
>
> Thanks


begin:vcard 
n:Hoffman;Jason
tel;pager:972-568-1713
x-mozilla-html:FALSE
org:Software Concepts / MTM Consulting
adr:version:2.1;;;Dallas;TX;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Programmer/Instructor
note;quoted-printable:SUN Certified JAVA 1.1 Programmer.=0D=0AC programmer, UNIX instructor,=0D=0Aand JAVA instructor.=0D=0A
fn:Jason Hoffman
end:vcard



Re: JavaLinux for servlets

1999-02-17 Thread John Goerzen

On Wed, Feb 17, 1999 at 01:17:43AM -0800, Steve Byrne wrote:

>  > But what techincal advantage do they really give?  Java is slower, uses more
>  > system resources, etc.
> 
> John, if you don't like Java, can you please tell us why you feel it's
> necessary to clog this mailing list with your anti-Java sentiments?  I don't
> think it's being constructive. 

I am really getting annoyed with people picking out bits and pieces of what
I wrote.  You, and others, are taking it out of context.

I have explained the areas in which I feel Java has an advantage over other
languages -- for example, development of large-scale client GUIs.  I have
also explained the areas in which I feel Java has some catching up to do,
for example, tasks involving parsing.

If you feel that any particular language, including Java, is the best choice
for every possible task, then you need to take a larger view of reality. 
The fact is that Java is not the best in all areas.  Likewise, Perl is not
the best in all areas.  Neither is C.  For that matter, neither is Linux or
Windows.

You use the tool that's right for the job.  I use Java for some things, Perl
for some things, C for some, C++, shell scripting, etc.  All of them have
their unique advantages and disadvantages.

You would probably think me crazy to use shell scripting for a GUI.  While
technically possible, it would be horrendous code.  Likewise, I would
probably think that using Java for an application that does a lot of
complicated parsing of input, computation, and then generation of output
would not be wise; Perl is better suited to that task.  Similarly, if I were
writing a webserver or other server that could see high levels of load, C is
really the only good choice.  Perl and Java may require less code, but the
performance would not be the same simply because of the abstraction in order
to make it system-independant -- although Perl is closer to Unix than Java. 
The interpretation cost and memory overhead hurts, too.

Constructive criticism is a well-known useful device.  If I point out to the
Perl people that the lack of strong typing can make large projects
difficult, and thus make Java a better tool for the job, perhaps the Perl
people will consider adding typing to the language (and indeed, they are
doing so).  Likewise, if I point out to Java people that Java's parsing
capabilities are weak compared to Perl, perhaps they will add something to
help with that.  In the end, everone wins, because all the languages
improve.

I fail to see what's wrong with talking about Java's unique benefits and
problems in a Java list.

John



Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread John Goerzen

On Wed, Feb 17, 1999 at 09:51:51AM +0100, Chris Huebsch wrote:

> The first is a "non-java-at-all" Server. It has to create a new process
> when a request arives. Where? The system is almost at the limit? It is

NO.

I keep saying this and apparently nobody is listening.

Let me give you URLs then:

http://www.apache.org/related_projects.html#modperl

  "With mod_perl it is possible to write Apache modules entirely in Perl.
   In addition, the PERSISTENT interpreter embedded in the server avoids
   the overhead of starting an external interpreter and the penalty of
   Perl start-up time."  (emphasis mine)

http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm

  "FastCGI processes are persistent: after finishing a request, they wait
   for a new request instead of exiting."

  "FastCGI . . . multiplexes the environment information . . . [allowing]
   FastCGI programs to run on remote machines"

> > I do not, and have never, reccommended PHP3 for anything "serious", for just
> > these issues, and others.  But mod_perl and FastCGI are quite good for CGI.
> 
> Database-Access with php or perl may be simple with simple problems. But
> when the problem gets more complex the problems increase exponentially.
> For instance you change your database from oracle to informix. With php
> you may change all your pages and replace oracle_db_XXX() to
> informix_db_YYY(). In java you write a factory which creates the
> SQL-Statements and only change the factory. The remaining parts of your
> application/applet/servlet remain untouched

Perl has DBI, which is largely JDBC-like.  DBI is not quite as good as JDBC
for some things, but it is better for others.  DBI creates an abstraction
between the program and the database driver just as JDBC does.

> Java is not just a language! It is an very large API and a Virtual
> Machine too.
> And one usefull use of Applets: I wouldn't do my online-banking with
> ActiveAEKS or just SSL. A-X wouldn't run on a Sparc ;)

Hehe :-)

> There are some problems which require not much data-transfer but a lot
> of graphical work. I cannot imagine transferring every single screen via
> X-protocol. (Embedded X is a X-Server inside the browser - isn't it?)

Essentially yes.  Which is the reason for my comment that, even with X
protocol compression, it's probably not good for much other than a LAN, and
even there it suffers from the same problems that Java does.

My point is that applets and embedded X are answers to a question that
nobody asked :-)

I know that Java is a VM, bytecode, etc.  What I'm trying to say is that
this is irrelevant -- HTML and the Web are simply the wrong paradigm for
trying to deploy full-fledged applications.

> > I have never disagreed that a Java-based GUI application (note, not applet)
> > as a client would be good, and in fact, in the message to which you are
> > replying, you snipped the part where I said so.
> 
> As already written - why to risk serious trouble by mixing lots of
> different technologies when you can use one? (If you really need peak
> performance you could use JNI with ANSI-C on the serverside)

Clouding the issue again :-)

The comments regarding applets have nothing to do with C or JNI.  Again I'm
trying to say that applets do not make sense in the context of HTML.  It's
not Java's fault, it's just how things are.

> > I wish people would stop comparing a current Java idea with an outdated CGI
> > one.  If you want to compare it to CGI, please do us the favor and compare
> > it to current CGI ideas.
> 
> And I wish people would stop comparing a current CGI idea with an
> outdated Java one ;)
> Java was designed with JITs in mind. Why would the bytecode assume a
> stack-architecture (which is simmilar to intermediate-code of "normal"
> compilers) if not to compile the last stage?

I've never denied JAva's thread abilities or JIT capabilities, nor bytecode,
and the like.  I frankly don't see its relevance for applications vs.
applets, as I've already granted you that performance is not so critical
there.

> public class chu extends ChrisHübsch implements TUChemnitz {

OK, you have beeen programming Java WAY too much :-)

>   String  email= "mailto:[EMAIL PROTECTED]";
>   String  SMSMail  = "mailto:[EMAIL PROTECTED]?Subject=SMS: info";
>   URL homepage = new URL("http://www.tu-chemnitz.de/~chu/");
>   Talktalkto   = new Talk("[EMAIL PROTECTED]");
>   Integer ePlus= new Integer(4628555);
> }



Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread John Goerzen

You are correct, Alex.  Both Solaris and Linux support "real" threads, as do
several other Unix OSs.  We can go into detail if need be, but I hope we can
spare the list that :-)

On Wed, Feb 17, 1999 at 01:32:38PM +0300, Alex Romadinoff wrote:

> >AFAIK unix doesn't support real threads. For new requests a new instance
>   
> ?
> >of the CGI is created with fork() or something like that? Now imagine a
> >server with a load around 99%.
> 
> 
> Are you sure ?
> What about 'clone' on Linux ?
> 
> With best wishes,
> Alex Romadinoff



Re: JavaLinux for servlets

1999-02-17 Thread Jan-Henrik Haukeland

John Goerzen <[EMAIL PROTECTED]> writes:

>*
> I have explained the areas in which I feel Java has an advantage
> over other languages -- for example, development of large-scale
> client GUIs.

Yeah and you're wrong. Java sucks big time as a GUI frontend. (Just
check out a fairly large system like NetBeans). It doesn't help either
that the pencil neck Swing developers are changing the api with each
new release. And the new Java 1.2 release makes me really sick by its
bugge javax.swing packages. 

> I have also explained the areas in which I feel Java has some
> catching up to do, for example, tasks involving parsing.

If you're comparing java's abillity for parsing strings with perl's
regexp you're missing the point. If your talking about creating a
parsergenerator in java then you are also missing the point. There
exists for instance two very good ll(k) parser-generators, AntLr and
JavaCC, which are much better grammar-vise than yacc or bison which
are lr(1).

> *

-- 
Jan-Henrik Haukeland



Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread Matthew Hunter

On Wed, Feb 17, 1999 at 10:37:53AM -0600, John Goerzen wrote:
> On Wed, Feb 17, 1999 at 09:51:51AM +0100, Chris Huebsch wrote:
> 
> I know that Java is a VM, bytecode, etc.  What I'm trying to say is that
> this is irrelevant -- HTML and the Web are simply the wrong paradigm for
> trying to deploy full-fledged applications.

Actually, this depends on the application.  Using Java applets, you
*can* build full-fledged applications on the web in a meaningful way; it
is most appropriate for situations were your server and client process
are owned by the same entity (ie, a corporation) and you want to make
distribution and updates easier.  This is a reasonable thing to do.

Some other situations also make sense.  Consider, for example, a
tech-support webpage with a Java applet that lets you enter a
description of your problem and interact with the internal scheduling
mechanism to determine when to have a service visit?  Or even one that
allows you to talk to the tech support guy (assuming you have sound set
up properly, a microphone, etc) and gives him the chance to poke around
your system looking for the problem?

There are uses for applets, believe me.

Regarding servlets, I wouldn't say they are necessarily technically
better than any other form of CGI (when coupled with an expert who
already understands them), but they have significant non-technical
benefits.  

-- 
Matthew Hunter ([EMAIL PROTECTED])



Re: JDK 1.2 Snapshots???

1999-02-17 Thread Paolo Ciccone


> "SB" == Steve Byrne <[EMAIL PROTECTED]> writes:

SB> I'll do something that I'm going to no doubt regret in the
SB> fullness of time: disclose my plans ahead of time.

That's great, thanks.

--Paolo



Re: jdk 1.1.7.1a / tya 1.2v3 performance?

1999-02-17 Thread Artur Biesiadowski

"Joseph H. Buehler" wrote:

> That's about 14 microseconds per loop, which is very slow, given what
> the code is doing on each pass through the loop: setting a bit in a
> bit array.
> 
> Preallocating the BitSet doesn't change things.  I installed tya using
> egcs, and tried various optimization flags, and some minor variations
> in tyaconfig.h, but the timing does not vary a whole lot.
> 
> Do these results seem reasonable?

You have not given results for jdk without tya. I've done few tests, and
tya gives me 2.5x speedup on this test. For comparison symcjit is about
16x faster. After some divisions I came up with following numbers (all
are quite rounded)

5000 cycles per iteration for plain jdk
1900 cycles per iteration for tya
300 cycles per iteration for symcjit

I think that that are quite reasonable number if you think about all
things that have to be done. For set method there are about 4 method
calls that need to be done + one synchronization. Additional problem is
that BitSet uses longs internally which causes a major slowdown on
intel.

Try to rewrite your benchmark using explicit array of ints, preallocated
to correct size, and then just fill it bit after bit. This way you will
get bare speed of java, without BitSet overhead. BitSet was not designed
to perform as buffer for image manipulation.

Artur



Re: JavaLinux for servlets

1999-02-17 Thread Jeff Galyan

Okay, time for me to step into the fray.

Here's how this works:

When a webserver (let's say Apache) gets a request from a client to run
a traditional CGI, the server spawns a new process *independent* of
itself. If the process is a Perl process, then it has the overhead of
initialization, reading in the file, parsing, etc. *before* it can do
anything useful to the end user.

If you have a servlet engine installed (say, Apache JServ), then when
the webserver gets a request for a servlet to be run, the server just
passes the request to the servlet engine *which is already running*,
which then passes the servlet info to the JVM *which is already running*
and the JVM spawns a Java thread on top of itself to handle the servlet
request. This all happens in very short order. If I recall correctly, an
ISP in San Francisco did some tests of Perl CGIs and Java servlets
side-by-side, both doing *exactly* the same things, and found that the
servlets ran on the order of 10 times faster than Perl, and produced a
significantly lower overhead on the server (I think the exact data are
on java.sun.com somewhere -that's where I first saw it about a year
ago). The reason for the difference? The servlets don't have to start a
new JVM process for each request, whereas Perl CGIs have to start a new
Perl process for each request. 

This is not to say that Perl isn't better suited for some tasks when you
restrict yourself *only* to the "core" Perl distribution.
Pattern-matching and other such niceties are truly wonderful builtins.
But if someone wants to use Java on their server, unless there is a very
compelling reason not to, I don't see any reason to try to convince them
otherwise.

By the way, java.sun.com is served from Java WebServer, and uses
servlets for almost everything, as does sun.com. So, before you dismiss
Java as a "toy", take a look at those two sites. You might be surprised
to see how much functionality is there, and how fast they serve.

John Goerzen wrote:
> 
> On Wed, Feb 17, 1999 at 01:17:43AM -0800, Steve Byrne wrote:
> 
> >  > But what techincal advantage do they really give?  Java is slower, uses more
> >  > system resources, etc.
> >
> > John, if you don't like Java, can you please tell us why you feel it's
> > necessary to clog this mailing list with your anti-Java sentiments?  I don't
> > think it's being constructive.
> 
> I am really getting annoyed with people picking out bits and pieces of what
> I wrote.  You, and others, are taking it out of context.
> 
> I have explained the areas in which I feel Java has an advantage over other
> languages -- for example, development of large-scale client GUIs.  I have
> also explained the areas in which I feel Java has some catching up to do,
> for example, tasks involving parsing.
> 
> If you feel that any particular language, including Java, is the best choice
> for every possible task, then you need to take a larger view of reality.
> The fact is that Java is not the best in all areas.  Likewise, Perl is not
> the best in all areas.  Neither is C.  For that matter, neither is Linux or
> Windows.
> 
> You use the tool that's right for the job.  I use Java for some things, Perl
> for some things, C for some, C++, shell scripting, etc.  All of them have
> their unique advantages and disadvantages.
> 
> You would probably think me crazy to use shell scripting for a GUI.  While
> technically possible, it would be horrendous code.  Likewise, I would
> probably think that using Java for an application that does a lot of
> complicated parsing of input, computation, and then generation of output
> would not be wise; Perl is better suited to that task.  Similarly, if I were
> writing a webserver or other server that could see high levels of load, C is
> really the only good choice.  Perl and Java may require less code, but the
> performance would not be the same simply because of the abstraction in order
> to make it system-independant -- although Perl is closer to Unix than Java.
> The interpretation cost and memory overhead hurts, too.
> 
> Constructive criticism is a well-known useful device.  If I point out to the
> Perl people that the lack of strong typing can make large projects
> difficult, and thus make Java a better tool for the job, perhaps the Perl
> people will consider adding typing to the language (and indeed, they are
> doing so).  Likewise, if I point out to Java people that Java's parsing
> capabilities are weak compared to Perl, perhaps they will add something to
> help with that.  In the end, everone wins, because all the languages
> improve.
> 
> I fail to see what's wrong with talking about Java's unique benefits and
> problems in a Java list.
> 
> John

-- 
Jeff Galyan
http://www.anamorphic.com
http://www.sun.com
jeffrey dot galyan at sun dot com
talisman at anamorphic dot com
Sun Certified Java(TM) Programmer
==
Linus Torvalds on Microsoft and software development:
"... if it

Re: JavaLinux for servlets

1999-02-17 Thread Ryan Sutter

Can we PLEASE stop this inane thread?  It's pointless.  Some people like
Java for everything, some for certain things, others for nothing at all.
I don't see what those people are doing on this list and I don't see how
any of this is relevant to Java on Linux.  You don't like Swing?  Fine.
Don't use it.  However, don't just rip on it because you think it's junk
without something to back it up other than "it's too slow".  I'm working
for a company in the final stages of a sizable commercial Java/Swing
development project.  We use Java/Swing on the client, servlets and
Java/JNI stuff for performance in our middleware that communicates back
to our database.  It scales well, runs well (extensively tested on Mac,
Windows, Irix and Linux), looks great and has been developed in a very
short period of time.  For our needs, Java is the only technology that
could have done all this and it's done it very very well.  Our users are
happy, our developers are happy and it's all because of Java.  Our
biggest bottlenecks have involved network traffic, not GUI performance
and that has nothing to do with Java.  SO, this stuff works...not
perfectly but darn well and it's certainly better then any of the other
options available for the majority of "corporate" application development
needs.  Don't argue Java vs. perl vs. PHP vs. C vs. whatever...it's
pointless.  Accept the fact that Java is a great tool for a lot of
things, use it for those things and use other technologies where
appropriate and leave the rest of us alone.  We don't care about your
opinions.

Ryan Sutter




JDK 1.2 source code available.

1999-02-17 Thread Ulrich Kortenkamp

Hi,

I just noticed a message on http://www.javalobby.org saying that the
JDK-1.2 source is available now. Maybe that's useful for all the
people that do not want to wait for the linux port ;-)

Ulli
--
http://www.cinderella.de



More evil from Microsoft [Off topic]

1999-02-17 Thread Harold G. Andrews II

When I looked at javalobby for the information regarding the JDK 1.2 Source
Release, I noticed another article about a new programming language
Microsoft is contemplating to get itself out from the litigation it's
currently in with Sun.  Thought you might enjoy reading the story
yourselves.  Enjoy

http://www.usatoday.com/life/cyber/zd/zd6.htm

-Andy



Re: JDK 1.2 source code available.

1999-02-17 Thread Brett W. McCoy

On 17 Feb 1999, Ulrich Kortenkamp wrote:

> I just noticed a message on http://www.javalobby.org saying that the
> JDK-1.2 source is available now. Maybe that's useful for all the
> people that do not want to wait for the linux port ;-)

Yes, and then we'll get a million posts instead of people who download 
the source and want to know why it won't compile under Linux... 

Brett W. McCoy   
 http://www.lan2wan.com/~bmccoy
---
People who are funny and smart and return phone calls get much better
press than people who are just funny and smart.
-- Howard Simons, "The Washington Post"

- BEGIN GEEK CODE BLOCK -
Version: 3.12
GAT dpu s:-- a C UL$ P+ L+++ E W++ N- o K- w--- O@ M-@ !V PS+++ 
PE Y+ PGP- t++ 5- X+ R+@ tv b+++ DI+++ D+ e>++ h+ r++ y
-- END GEEK CODE BLOCK --



Re: JavaLinux for servlets

1999-02-17 Thread John Goerzen

OK, this is about the 6th or 7th time I've said this and STILL people are
ignoring it.

Your whole argument is based on a flawed premise: that with CGI, a new
process must be started for each request.  This is plain and simply NOT
correct.  I have pointed this out time and time again.

Any benchmarks comparing Java to this sort of thing are misleading at best,
and more likely downright incorrect.

If people want to discuss the performance of mod_perl or FastCGI vs.
servelts, please do so.  But please cease this misleading practice of
comparing current Java to outdated Perl.

In <[EMAIL PROTECTED]>, I wrote:

I keep saying this and apparently nobody is listening.

Let me give you URLs then:

http://www.apache.org/related_projects.html#modperl

  "With mod_perl it is possible to write Apache modules entirely in Perl.
   In addition, the PERSISTENT interpreter embedded in the server avoids
   the overhead of starting an external interpreter and the penalty of
   Perl start-up time."  (emphasis mine)

http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm

  "FastCGI processes are persistent: after finishing a request, they wait
   for a new request instead of exiting."

  "FastCGI . . . multiplexes the environment information . . . [allowing]
   FastCGI programs to run on remote machines"

On Wed, Feb 17, 1999 at 11:10:12AM -0700, Jeff Galyan wrote:

> When a webserver (let's say Apache) gets a request from a client to run
> a traditional CGI, the server spawns a new process *independent* of
> itself. If the process is a Perl process, then it has the overhead of
> initialization, reading in the file, parsing, etc. *before* it can do
> anything useful to the end user.

Not if using mod_perl or FastCGI, as I have kept saying.  As the rest of
your post relies on this flawed assumption, there isn't much else to say.



NO MORE--JavaLinux for servlets

1999-02-17 Thread Jason Hoffman

PLEASE, PLEASE, PLEASE!  Take this offline... This list has a SPECIFIC
purpose, and this discussion is NOT it.  Please reply directly to the sender,
AND NOT THE LIST.

PLEASE, JOHN!
PLEASE, EVERYONE ELSE!

Thank You!



Re: JavaLinux for servlets

1999-02-17 Thread Tom Jenkins

> Okay, time for me to step into the fray.
> 
> Here's how this works:
> 
No, that is how one way works...
If you run Apache using either mod_perl, pyapache(aka mod_python) or 
FastCGI then the server does NOT spawn a new process for the cgi 
script.  It passes the request to the cgi script *which is already 
running*, which then handles it (sounds familiar).  

The difference between FastCGI and mod_* is that the mods expose the 
apache API to interpreter be it Perl, Python, whatever.


> When a webserver (let's say Apache) gets a request from a client to run
> a traditional CGI, the server spawns a new process *independent* of
> itself. If the process is a Perl process, then it has the overhead of
> initialization, reading in the file, parsing, etc. *before* it can do
> anything useful to the end user.
> 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Jenkins  
DevIS  
Linux & Samba 2.0 : The best Windows file server
http://www.zdnet.com/sr/stories/issue/0,4537,2196106,00.html   
  
"Do not be overcome by evil, but overcome evil with good." Romans 12:21



Re: JavaLinux for servlets

1999-02-17 Thread Jeff Galyan

Pardon me, but you appear to be the ONLY person actually using mod_perl
or FastCGI in a production environment. 

As for my assumptions being "flawed", that would mean that the
developers at Java Software (formerly JavaSoft) don't know what they're
talking about either, nor do the course developers at Sun Educational
Services, nor do anyone else I work with at Sun.

Perhaps the reason people are ignoring your argument against using Java
is because your argument is, plain and simple, wrong.

Now I hope this puts an end to this stupid thread.


John Goerzen wrote:
> 
> OK, this is about the 6th or 7th time I've said this and STILL people are
> ignoring it.
> 
> Your whole argument is based on a flawed premise: that with CGI, a new
> process must be started for each request.  This is plain and simply NOT
> correct.  I have pointed this out time and time again.
> 
> Any benchmarks comparing Java to this sort of thing are misleading at best,
> and more likely downright incorrect.
> 
> If people want to discuss the performance of mod_perl or FastCGI vs.
> servelts, please do so.  But please cease this misleading practice of
> comparing current Java to outdated Perl.
> 
> In <[EMAIL PROTECTED]>, I wrote:
> 
> I keep saying this and apparently nobody is listening.
> 
> Let me give you URLs then:
> 
> http://www.apache.org/related_projects.html#modperl
> 
>   "With mod_perl it is possible to write Apache modules entirely in Perl.
>In addition, the PERSISTENT interpreter embedded in the server avoids
>the overhead of starting an external interpreter and the penalty of
>Perl start-up time."  (emphasis mine)
> 
> http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm
> 
>   "FastCGI processes are persistent: after finishing a request, they wait
>for a new request instead of exiting."
> 
>   "FastCGI . . . multiplexes the environment information . . . [allowing]
>FastCGI programs to run on remote machines"
> 
> On Wed, Feb 17, 1999 at 11:10:12AM -0700, Jeff Galyan wrote:
> 
> > When a webserver (let's say Apache) gets a request from a client to run
> > a traditional CGI, the server spawns a new process *independent* of
> > itself. If the process is a Perl process, then it has the overhead of
> > initialization, reading in the file, parsing, etc. *before* it can do
> > anything useful to the end user.
> 
> Not if using mod_perl or FastCGI, as I have kept saying.  As the rest of
> your post relies on this flawed assumption, there isn't much else to say.

-- 
Jeff Galyan
http://www.anamorphic.com
http://www.sun.com
jeffrey dot galyan at sun dot com
talisman at anamorphic dot com
Sun Certified Java(TM) Programmer
==
Linus Torvalds on Microsoft and software development:
"... if it's a hobby for me and a job for you, why are you doing such a
shoddy job of it?"

The views expressed herein do not necessarily reflect those of my
employer.

Sun Microsystems, Inc., has no connection to my involvement with the
Mozilla Organization.



RE: problem jdk1.2

1999-02-17 Thread Patrick Lam

I ocassionally got the same thing too!  Still don't know what causes it.
Most of the time a programs works fine, but suddenlly it returns this
message (probably after a did something, but I can't recall).

I thought that's my machine's problem, Now I think it might not be that
simple.

BTW, I have both jdk1.2 and MS SDK 3.1 and MS VM (latest) installed.

Any pointer??

Thanks.

Patrick.

-Original Message-
From: Ozer Irfan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 17, 1999 6:23 AM
To: Carl H. Sayres
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: problem jdk1.2


I have this message


Exception in thread "main' java.lang.NoClassDefFoundError

when I run

java test1

With javac I don't have problems

this is the program


import java.io.* ;

public class test1 {
public static void main(String args []) {

System.out.println("Hello");
}
}


Thanks



Re: JavaLinux for servlets

1999-02-17 Thread John Goerzen

On Wed, Feb 17, 1999 at 12:39:57PM -0700, Jeff Galyan wrote:

> Pardon me, but you appear to be the ONLY person actually using mod_perl
> or FastCGI in a production environment. 

I know of multiple organizations using mod_perl in a production environment. 
If memory serves, hotmail is one, but that could be incorrect.

> As for my assumptions being "flawed", that would mean that the
> developers at Java Software (formerly JavaSoft) don't know what they're
> talking about either, nor do the course developers at Sun Educational
> Services, nor do anyone else I work with at Sun.

I fail to see how your failure to realize that CGI is not a stone ages
technology has any bearing on Sun.  What marketing types and the real
programmers say and do can be very different things.  It is unfortunately
not all that uncommon to compare a current version of one's own product to
an outdated one from someone else for marketing purposes.

> Perhaps the reason people are ignoring your argument against using Java
> is because your argument is, plain and simple, wrong.

How so?

> Now I hope this puts an end to this stupid thread.



Re: NO MORE--JavaLinux for servlets

1999-02-17 Thread John Goerzen

Shall we all send unsubscribe requests and 1.2 questions instead?  :-)

(Gotta keep the traffic up somehow, you know)

Anyway, *cough* caps lock...

On Wed, Feb 17, 1999 at 01:25:43PM -0600, Jason Hoffman wrote:

> PLEASE, PLEASE, PLEASE!  Take this offline... This list has a SPECIFIC
> purpose, and this discussion is NOT it.  Please reply directly to the sender,
> AND NOT THE LIST.
> 
> PLEASE, JOHN!
> PLEASE, EVERYONE ELSE!
> 
> Thank You!



Re: jdk 1.1.7.1a / tya 1.2v3 performance?

1999-02-17 Thread David Craig

Is symcjit, the Symantec JIT running on WinNT?  I'd greatly appreciate
finding out more, but to my knowledge the available JITs are TYA and
shuJIT for the port of Sun's VM and the JIT within Kaffe.

shuJIT doesn't appear to be mentioned very often in performance
comparisons in this list.  Its website boasts performance results that are
usually better than TYA 1.2v3, and I'd be curious to hear about it's ease
of use. (http://www.shudo.net/jit/)

David Craig
e-mail: [EMAIL PROTECTED], the rest: http://www.csrd.uiuc.edu/~dcraig

On Wed, 17 Feb 1999, Artur Biesiadowski wrote:

> "Joseph H. Buehler" wrote:
> 
> > That's about 14 microseconds per loop, which is very slow, given what
> > the code is doing on each pass through the loop: setting a bit in a
> > bit array.
> > 
> > Preallocating the BitSet doesn't change things.  I installed tya using
> > egcs, and tried various optimization flags, and some minor variations
> > in tyaconfig.h, but the timing does not vary a whole lot.
> > 
> > Do these results seem reasonable?
> 
> You have not given results for jdk without tya. I've done few tests, and
> tya gives me 2.5x speedup on this test. For comparison symcjit is about
> 16x faster. After some divisions I came up with following numbers (all
> are quite rounded)
> 
> 5000 cycles per iteration for plain jdk
> 1900 cycles per iteration for tya
> 300 cycles per iteration for symcjit
> 
> I think that that are quite reasonable number if you think about all
> things that have to be done. For set method there are about 4 method
> calls that need to be done + one synchronization. Additional problem is
> that BitSet uses longs internally which causes a major slowdown on
> intel.
> 
> Try to rewrite your benchmark using explicit array of ints, preallocated
> to correct size, and then just fill it bit after bit. This way you will
> get bare speed of java, without BitSet overhead. BitSet was not designed
> to perform as buffer for image manipulation.
> 
> Artur
> 



Java Plugin (Activator)

1999-02-17 Thread Arend Meetsma

Hi there.
I'm looking for a version of the Java Plugin/Activator for Linux.
The Javasoft site pointed me to www.blackdown.org/activator/index.html ,
but this page doesn't seem to exist.
Is this product no longer avaiable?

Thanks in advance.
Arend Meetsma



Re: Who to make templates?

1999-02-17 Thread Robert Ritchy

I completed the project last summer and we wrote our own parser which
recognized SSI-like tags.  Since that time I've realized that there are
better ways of implementing that type of solution.
>From what I can tell, the options for "expanding" HTML pages with
dynamic data are as follows:

Web server-dependent SSI tags
Web server specific scripting languages (Netscape/LiveWire,
Microsoft/Active Server Pages, etc.)
Application Servers usually provide their own template schemes (NAS,
WebLogic, etc.)
JSP (Java Server Pages) seems to be gaining in popularity
And finally, (my preference) - XML based templates.  You can create a
completely portable and customizable template engine that's not
dependent on your product choices.

Contrary to some, I think that portability is important for web server
apps - especially if you want to use them again with different
solutions/environments.  So, if I did it again (and I didn't have an App
Server handy), I would use one of the several, freely available, XML
parsers to implement a XML/DOM/SAX-like solution.  I would not use JSP
(embedding javabeans and related tags into the HTML file) because I
believe that a web designer would be the person maintaining those pages,
not a developer.  With JSP this web page designer would have to know
about the database instance name/location, javabean name/parameters and
other implementation specifics.  IMHO - the presentation layer should be
*completely* separate from your logic.

I sure hope this doesn't spark another heated debate.  If I'm wrong
about anything or anyone has a different opinion, please correct me
nicely ;>)

delicate self esteem -
Robert

Marcel Ruff wrote:

> Hi
>
> you wrote about servlets and html-templates.
> What possibilities are there to make html-templates
> and where is there a good parser to build the final html file
> from the template?
>
> thanks, Marcel
>
> --
> Marcel Ruff
> [EMAIL PROTECTED]
> http://www.lake.de/home/lake/swand/


begin:vcard 
n:Ritchy;Robert
x-mozilla-html:FALSE
org:BDM Denver
adr:;;1999 Broadway - Suite 2000;Denver;CO;80202;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Development TL
x-mozilla-cpt:;2
tel;work:303-672-8917 / 247-1150 ex 8917
fn:Robert Ritchy
end:vcard



RE: JavaLinux for servlets

1999-02-17 Thread Lasorsa, Vince

I agree with John on this one! USe the right tool for the job... You and
your users will appreciate a craftsman who understands his/her toolbox!

-Original Message-
From: John Goerzen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 17, 1999 11:09 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: JavaLinux for servlets


On Wed, Feb 17, 1999 at 01:17:43AM -0800, Steve Byrne wrote:

>  > But what techincal advantage do they really give?  Java is slower, uses
more
>  > system resources, etc.
> 
> John, if you don't like Java, can you please tell us why you feel it's
> necessary to clog this mailing list with your anti-Java sentiments?  I
don't
> think it's being constructive. 

I am really getting annoyed with people picking out bits and pieces of what
I wrote.  You, and others, are taking it out of context.

I have explained the areas in which I feel Java has an advantage over other
languages -- for example, development of large-scale client GUIs.  I have
also explained the areas in which I feel Java has some catching up to do,
for example, tasks involving parsing.

If you feel that any particular language, including Java, is the best choice
for every possible task, then you need to take a larger view of reality. 
The fact is that Java is not the best in all areas.  Likewise, Perl is not
the best in all areas.  Neither is C.  For that matter, neither is Linux or
Windows.

You use the tool that's right for the job.  I use Java for some things, Perl
for some things, C for some, C++, shell scripting, etc.  All of them have
their unique advantages and disadvantages.

You would probably think me crazy to use shell scripting for a GUI.  While
technically possible, it would be horrendous code.  Likewise, I would
probably think that using Java for an application that does a lot of
complicated parsing of input, computation, and then generation of output
would not be wise; Perl is better suited to that task.  Similarly, if I were
writing a webserver or other server that could see high levels of load, C is
really the only good choice.  Perl and Java may require less code, but the
performance would not be the same simply because of the abstraction in order
to make it system-independant -- although Perl is closer to Unix than Java. 
The interpretation cost and memory overhead hurts, too.

Constructive criticism is a well-known useful device.  If I point out to the
Perl people that the lack of strong typing can make large projects
difficult, and thus make Java a better tool for the job, perhaps the Perl
people will consider adding typing to the language (and indeed, they are
doing so).  Likewise, if I point out to Java people that Java's parsing
capabilities are weak compared to Perl, perhaps they will add something to
help with that.  In the end, everone wins, because all the languages
improve.

I fail to see what's wrong with talking about Java's unique benefits and
problems in a Java list.

John



Re: JavaLinux for servlets [off-topic]

1999-02-17 Thread Brett W. McCoy

On Tue, 16 Feb 1999, Nathan Meyers wrote:

> Whoa... how did this discussion suddenly become religious?

Whenever you mention a foreign language in a mailing list devoted to a
certain language, it *always* becomes religious.

Brett W. McCoy   
http://www.lan2wan.com/~bmccoy/
---
In America, any boy may become president and I suppose that's just one
of the risks he takes.
-- Adlai Stevenson

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GAT dpu s:-- a C UL$ P+ L+++ E W++ N+ o K- w--- O@ M@ !V PS+++
PE Y+ PGP- t++ 5- X+ R+@ tv b+++ DI+++ D+ G++ e>++ h+(---) r++ y
--END GEEK CODE BLOCK--



Re: NO MORE--JavaLinux for servlets

1999-02-17 Thread Brett W. McCoy

On Wed, 17 Feb 1999, Jason Hoffman wrote:

> PLEASE, PLEASE, PLEASE!  Take this offline... This list has a SPECIFIC
> purpose, and this discussion is NOT it.  Please reply directly to the sender,
> AND NOT THE LIST.

On the other hand, it's breathed some life into the list and distracted us
from the "when 1.2 be ready" messages.

Brett W. McCoy   
http://www.lan2wan.com/~bmccoy/
---
Reality must take precedence over public relations, for Mother Nature
cannot be fooled.
-- R.P. Feynman

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GAT dpu s:-- a C UL$ P+ L+++ E W++ N+ o K- w--- O@ M@ !V PS+++
PE Y+ PGP- t++ 5- X+ R+@ tv b+++ DI+++ D+ G++ e>++ h+(---) r++ y
--END GEEK CODE BLOCK--



RE: JavaLinux for servlets

1999-02-17 Thread Steve Byrne

Lasorsa, Vince writes:
 > I agree with John on this one! USe the right tool for the job... You and
 > your users will appreciate a craftsman who understands his/her toolbox!

Wise words...

 > -Original Message-
 > From: John Goerzen [mailto:[EMAIL PROTECTED]]
 > Sent: Wednesday, February 17, 1999 11:09 AM
 > To: [EMAIL PROTECTED]
 > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 > [EMAIL PROTECTED]; [EMAIL PROTECTED]
 > Subject: Re: JavaLinux for servlets
 > 
 > 
 > On Wed, Feb 17, 1999 at 01:17:43AM -0800, Steve Byrne wrote:
 > 
 > >  > But what techincal advantage do they really give?  Java is slower, uses
 > more
 > >  > system resources, etc.
 > > 
 > > John, if you don't like Java, can you please tell us why you feel it's
 > > necessary to clog this mailing list with your anti-Java sentiments?  I
 > don't
 > > think it's being constructive. 
 > 
 > I am really getting annoyed with people picking out bits and pieces of what
 > I wrote.  You, and others, are taking it out of context.
[switching gears to respond to John]

I'm sorry, but all I saw from your sudden burst of postings was anti-Java.  

 > I have explained the areas in which I feel Java has an advantage over other
 > languages -- for example, development of large-scale client GUIs.  I have
 > also explained the areas in which I feel Java has some catching up to do,
 > for example, tasks involving parsing.
 > 
 > If you feel that any particular language, including Java, is the best choice
 > for every possible task, then you need to take a larger view of reality. 
 > The fact is that Java is not the best in all areas.  Likewise, Perl is not
 > the best in all areas.  Neither is C.  For that matter, neither is Linux or
 > Windows.

Well -- I resist the bait.

 > You use the tool that's right for the job.  I use Java for some things, Perl
 > for some things, C for some, C++, shell scripting, etc.  All of them have
 > their unique advantages and disadvantages.

True.

 > Constructive criticism is a well-known useful device.  If I point out to the
 > Perl people that the lack of strong typing can make large projects
 > difficult, and thus make Java a better tool for the job, perhaps the Perl
 > people will consider adding typing to the language (and indeed, they are
 > doing so).  Likewise, if I point out to Java people that Java's parsing
 > capabilities are weak compared to Perl, perhaps they will add something to
 > help with that.  In the end, everone wins, because all the languages
 > improve.
 > 
 > I fail to see what's wrong with talking about Java's unique benefits and
 > problems in a Java list.

Ok.   Let me be REAL clear to you.  Your thinking here is confused.  You
believe java-linux to be "*a* Java list"; i.e. you see is as equivalent to
comp.lang.java.  It is not.  It is for discussing issues related to Java on
Linux.  If you want to engage in debates about larger issues which are really
Linux independent, then this is NOT THE PLACE FOR YOU.  I don't think that I've
seen anything that you have written criticizing Java is specifically Linux Java
related, and thus it constitutes a poor and inappropriate use of bandwidth to
announce your generic opinions on java-linux.  

The comp.lang.java* news groups are a much better place to talk about the
generic benefits and problems with the Java platform than java-linux.  Please
use them for expressing your generic Java views, ok?   Thanks.

Steve



Re: JavaLinux for servlets

1999-02-17 Thread John Goerzen

On Wed, Feb 17, 1999 at 07:23:04PM -0800, Steve Byrne wrote:

> I'm sorry, but all I saw from your sudden burst of postings was anti-Java.  

Perhaps you would realize that I did not start this thread?

I was replying to a message that stated:

> 4. Linux evangelists : Linux is the future. Java is a fad that will
>probably be overtaken by something else eventually. Think that Java
>does not have the best licensing model (it's not GPL). Java is slow
>because Perl kicks ass in CGI (have never heard of servlets). Can't
>understand why we don't just have a Java to native compiler,

I do not understand why you are criticizing me for replying to that.  If
that post was on-topic, which it seems to be, how can a topical reply not
be?

Note that in my reply, I mentioned:

  A valid categorization, I believe.  I clearly belong best to #4, but a
  difference is that I believe that Linux will be overtaken by something else. 
  Hurd, for instance, when it gets more stable (but we're looking at years
  here).  

Clearly Linux-related.  Again, people ignore that part of my message.

I then go on to talk about Java, how it relates to Unix (and Linux), and
then CGI.  This was in <[EMAIL PROTECTED]>.

>  > I fail to see what's wrong with talking about Java's unique benefits and
>  > problems in a Java list.
> 
> Ok.   Let me be REAL clear to you.  Your thinking here is confused.  You
> believe java-linux to be "*a* Java list"; i.e. you see is as equivalent to
> comp.lang.java.  It is not.  It is for discussing issues related to Java on

I never said that.

> Linux.  If you want to engage in debates about larger issues which are really
> Linux independent, then this is NOT THE PLACE FOR YOU.  I don't think that I've
> seen anything that you have written criticizing Java is specifically Linux Java
> related, and thus it constitutes a poor and inappropriate use of bandwidth to
> announce your generic opinions on java-linux.  

I was not announcing my generic opinions about Java.  I was replying to
others.

And if you think that Apache, CGI, web servers, and the like are not
Linux-related, well, please take a look at your neighborhood Linux
distribution and realize that they are.

Note that we would not be talking about Apache or Perl for CGI if this was a
Windows platform, or even many Unices.

> The comp.lang.java* news groups are a much better place to talk about the
> generic benefits and problems with the Java platform than java-linux.  Please
> use them for expressing your generic Java views, ok?   Thanks.

I'm quite willing, and would be glad, to see this thread die.  But the
rather brutal attack that I have suffered for merely pointing out that Java
is not always the best is not really justified.  I did not start the thread. 
I was agreeing with one particular option set forth by another person.  It
started out Linux-related.  My reply was Linux-related.  When people started
replying to me, they chopped out parts of my messages.  They did not reply
to the whole message.  Several people in here even were thinking that I was
completely against Java, even after I recommended it for some types of
projects!  (People never quoted that.) I use Java.  I also use other
languages.  What am I supposed to do here, refuse to answer because of
underhanded quoting techniques?

This whole thread has illustrated something: there is a lot of delusion of
grandeur here.  People must realize that no language is the best for
everything.  As a Linux developer, I have a very high opinion of Linux, but
I do recognize that it has its weaknesses that could make it unsuitable for
some people.  As someone that programs in Perl, I have a similar opinion. 
Likewise for Java, (despite its poor licensing; the core is good.)

John



Re: JavaLinux for servlets

1999-02-17 Thread Raju Karia

My original posting (entitled Java-linux enthusiasts) was about
categorizing
Java developers as belonging to one or more groups of users of
particular
platforms. I mentioned servlets in passing. I had no intention of
starting
a debate on servlets.

Now, why don't we stop bickering about whether Perl is superior to Java
(or vice versa) and get back to the original theme - what category do
you
belong to ? ;-)

Raju Karia

John Goerzen wrote:
> 
> On Wed, Feb 17, 1999 at 07:23:04PM -0800, Steve Byrne wrote:
> 
> > I'm sorry, but all I saw from your sudden burst of postings was anti-Java.
> 
> Perhaps you would realize that I did not start this thread?
> 
> I was replying to a message that stated:
> 
> > 4. Linux evangelists : Linux is the future. Java is a fad that will
> >probably be overtaken by something else eventually. Think that Java
> >does not have the best licensing model (it's not GPL). Java is slow
> >because Perl kicks ass in CGI (have never heard of servlets). Can't
> >understand why we don't just have a Java to native compiler,
> 
> I do not understand why you are criticizing me for replying to that.  If
> that post was on-topic, which it seems to be, how can a topical reply not
> be?
> 
> Note that in my reply, I mentioned:
> 
>   A valid categorization, I believe.  I clearly belong best to #4, but a
>   difference is that I believe that Linux will be overtaken by something else.
>   Hurd, for instance, when it gets more stable (but we're looking at years
>   here).
> 
> Clearly Linux-related.  Again, people ignore that part of my message.
> 
> I then go on to talk about Java, how it relates to Unix (and Linux), and
> then CGI.  This was in <[EMAIL PROTECTED]>.
> 
> >  > I fail to see what's wrong with talking about Java's unique benefits and
> >  > problems in a Java list.
> >
> > Ok.   Let me be REAL clear to you.  Your thinking here is confused.  You
> > believe java-linux to be "*a* Java list"; i.e. you see is as equivalent to
> > comp.lang.java.  It is not.  It is for discussing issues related to Java on
> 
> I never said that.
> 
> > Linux.  If you want to engage in debates about larger issues which are really
> > Linux independent, then this is NOT THE PLACE FOR YOU.  I don't think that I've
> > seen anything that you have written criticizing Java is specifically Linux Java
> > related, and thus it constitutes a poor and inappropriate use of bandwidth to
> > announce your generic opinions on java-linux.
> 
> I was not announcing my generic opinions about Java.  I was replying to
> others.
> 
> And if you think that Apache, CGI, web servers, and the like are not
> Linux-related, well, please take a look at your neighborhood Linux
> distribution and realize that they are.
> 
> Note that we would not be talking about Apache or Perl for CGI if this was a
> Windows platform, or even many Unices.
> 
> > The comp.lang.java* news groups are a much better place to talk about the
> > generic benefits and problems with the Java platform than java-linux.  Please
> > use them for expressing your generic Java views, ok?   Thanks.
> 
> I'm quite willing, and would be glad, to see this thread die.  But the
> rather brutal attack that I have suffered for merely pointing out that Java
> is not always the best is not really justified.  I did not start the thread.
> I was agreeing with one particular option set forth by another person.  It
> started out Linux-related.  My reply was Linux-related.  When people started
> replying to me, they chopped out parts of my messages.  They did not reply
> to the whole message.  Several people in here even were thinking that I was
> completely against Java, even after I recommended it for some types of
> projects!  (People never quoted that.) I use Java.  I also use other
> languages.  What am I supposed to do here, refuse to answer because of
> underhanded quoting techniques?
> 
> This whole thread has illustrated something: there is a lot of delusion of
> grandeur here.  People must realize that no language is the best for
> everything.  As a Linux developer, I have a very high opinion of Linux, but
> I do recognize that it has its weaknesses that could make it unsuitable for
> some people.  As someone that programs in Perl, I have a similar opinion.
> Likewise for Java, (despite its poor licensing; the core is good.)
> 
> John