Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

steel-wool panty liners = Java?



John Chambers wrote, On 08/04/2004 06:16 PM:
> David Kramer wrote:
> 
>>			...  I graduated from a SUNY
>>school with a BS in CS, and our curriculm was heavy focused on
>>programming theory, rather than languages. ...  The
>>point, or so we were told, is so that we can graduate and be adaptable
>>to any language we're asked to program in.
> 
> 
> Yeah; some schools do a pretty good job of that.  Not that this makes
> much  of an impression on employers, who mostly just want to know how
> many years experience you have with languages X, Y and Z.

That's mostly true.  But part of my speech when I'm interviewing is on my 
general software development skills and knowledge, and they seem to appreciate 
where the value is in that.  Of course I haven't been hired by them yet, so...


> OTOH, a major complaint I've had about java from the start  is  that,
> even  when it is available, I often can't discover how to use it.  If
> there are "javac" and "java" commands available, sometimes I can  use
> them,  though  sometimes  they're such wild variants of anything I've
> used before that I can't make much sense of them. It seems that there
> are  quite  a lot of different ways that java can be implemented, and
> some of them aren't very well documented.

I think you are confused about the different kinds of java applications.  If 
you are comparing text-mode, command line java applications, there simply has 
to be a "javac" command to compile them and a "java" command to execute them, 
and it should take the same parameters regardless of the distribution of Java. 
or the platform you are running on.  Furthermore, on a properly configured 
system, there will be an environment variable, $JAVA_HOME, that will tell you 
where java is installed.  Those commands will be in $JAVA_HOME/bin.  Always.

With C it's much worse.  If you want to compile a simple Hello World program 
under Visual Studio on Windows, knowing how to compile a simple Hello World 
program with gcc under Linux will not help you one bit.  Knowing how to write 
a textmode Hello World program on Windows will also not help you write a 
graphical Windows Hello World program on the very same computer.

But There are other kinds of java code, and perhaps that is the source of your 
confusion.  There are also utility classes, AWT apps, Swing apps, java 
servlets, java server pages, java beans, enterprise java beans, etc.  These 
are all different kinds of programs, and are not meant to be run from the 
commandline, and probably don't even have a main().

Again, the same is true under Windows.  You have textmode applications, MFC 
applications, DLL's, static libraries....

> An example that I like to give: If you open up a "C Bible" from  back
> in the 70's, and type in literally the "Hello, world" example, you'll
> find that it  works  unchanged.   (That  is  unless  you're  on  some
> Microsoft  systems,  as  usual  ;-).  Even that silly "a.out" name is
> still the default, a senseless relic of a long-gone linker  that  K&R
> used on an early machine. C has evolved a lot, and we've had many new
> C compilers, but they all preserve this useful bootstrap example.

If type in a HelloWorld.java program, I can compile it and run it just as well 
on java 1.4.3 or java from years ago,  It has not changed.  Please explain to 
me how it has.  You also point out the fallacy of your statement yourself by 
admitting that the command to compile helloworld.c will be different on 
different platforms.

> Chances are that the machine you're  using  now  actually  has  java,
> since most browsers now include it along with javascript. But lots of

**WRONG**
Most computers have the JRE, the Java Runtime Engine, which can execute 
bytecode compiled java programs.  That is not the same thing as having the 
J2SDK, which can compile java source code into bytecode compiled java 
programs.  That's like saying that because you have the Windows runtime DLL's 
on your system, you should be able to  write Windows programs and run them 
without a compiler.

> luck trying to figure out how to type in a simple  java  program  and
> run it.  And, unless you can get the dumb little "hello.java" program
> to run, all the sophisticated software design knowledge in the  world
> won't do you much good.

Again, give me an example where you cannot type in
//--------------- HelloWorld.java begins
public class HelloWorld {
	public static void main(String[] args) {
		System.out.println("Hello, World!");
	}
}
//--------------- HelloWorld.java endss
on any platform that has a properly installed J2SDK and JRE of any vintage, 
and run
    javac HelloWorld.java
    java HelloWorld
and not get the desired output.

> A really frustrating part of this is that an important  part  of  the
> original  design  of java was that it could run on tiny machines that
> were on a network.  You only needed to install the top-level  classes
> for  the  apps;  others  would be downloaded dynamically as they were
> needed.  This way, you didn't need to install  everything  you  might
> ever need, and memory was minimized.

Where did you read that?  Java was designed initially for small processor 
chips that natively supported the Java instruction set.  The whole 
cross-platform runtime engine, and then the web services stuff, was an 
afterthought thrown in later.

> But try using this on most of today's java implementations. One of my
> test  toys,  for example, is a BlackBerry 7280.  Cool gadget, and the
> software is entirely in java.  But to install anything, you  have  to
> copy  it  to  a  Windows  system, connect the BB to the machine's USB
> port, and run RIM's specialized tools to install things  in  the  BB.

That is Rim's implementation of how they install software, and has NOTHING to 
do with java.

There is no part of java designed to automatically download classes it needs 
from the internet, and as far as I know, there never was one.

> Yes,  the  device  has a full-time Internet connection, anywhere that
> there's GPRS or GSM service.  But you can't install software over the
> Net,  like  java  was  designed  to do.  So far, I've found that most
> installs take several tries, as the Windows code either crashes, goes
> zombie, or gives insane failure messages, different every time.

Well, it's Windows.  What can I say, but this too has nothing to do with java, 
and everything to do with Rim's implementation of a software distribution 
method.  Show me a language where you cannot write bad code that crashes.  If 
I buy a Mercedes Benz and use it to drive offroad, I'm not going to get an 
ultrasmooth ride, but that's because I'm doing stupid things with a fine tool, 
not because the tool is not fine.

-- 
DDDD   David Kramer         david at thekramers.net       http://thekramers.net
DK KD  Perhaps those of us who care about quality programs have not spoken
DKK D  up often enough- for bad programs to triumph requires only that good
DK KD  programmers remain silent.
DDDD   I call this passivity the `Silence of the Lambdas.'      -Henry Baker









BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org