Slashdot Mirror
Java Application Development on Linux
The authors, Carl Albing and Michael Schwarz, chose to create a book that is a complete guide to writing commercial-quality Java programs. With the burgeoning presence of Linux, they focused on how to use the tools of the Linux platform to assist in the creation and maintenance of Java programs. They have broken the book up into five major parts: Getting Started, Developing Business Logic, Developing Graphical User Interfaces, Developing Web Interfaces, and Developing Enterprise Scale Software. Each chapter is self-contained, and the knowledgeable reader can pick and choose what they would like to read without losing track. Carl and Michael have properly started each chapter with a summary of what you'll learn, and conclude with a What You Still Don't Know section. A Resources section is included to give you more references for further study.
Part 1, Getting Started, provides a 10-chapter overview of Linux, Java, the SDK's (Software Development Kits) from Sun and IBM, version control via CVS, and IDEs. The first two chapters cover enough command-line Linux to manage your files and directories, plus the Vi editor to create and edit your programs. Chapter 3 gives you a summarized but complete overview of the Java language (minus the standard classes), and Chapter 4 covers how the program can deal with the context in which it's running. The next two chapters cover Sun's SDK and (mainly for comparison) IBM's development kit. In some instances, the Java program may be so large and/or so complex that running the byte codes in the Virtual Machine may not be quick enough, so Chapter 7 describes how to use the GNU Compiler for Java (gcj) to create native-code programs.
Larger programs definitely need some form of source control (actually, any project larger than a classroom exercise needs it), so source control using CVS is clearly laid out for you. While other products are available, CVS (Concurrent Versioning System) is widely available, robust, mature, and reliable, so the authors chose to describe its use in detail. For building and deploying the numerous files of a larger project, Ant provides value beyond what the make facility can offer, especially with the RMI (Remote Method Invocation) dependency problems that make can't address. Finally, Integrated Development Environments are covered. While Carl and Michael focus on NetBeans, SunONE Studio Community Edition and Eclipse are also covered.
If the book stopped after Part I, you would still have a valuable addition to your bookshelf. However, it continues with a five-chapter discussion on how to properly develop business logic. One chapter is totally devoted to the business aspects of getting requirements, documentation, and buy-in. The next covers how to use a simple software development methodology to analyze the program and discover the objects to be created. The following chapter goes over a frequently overlooked aspect of programming - automated testing - with JUnit. The last two chapters of Part II cover storing data in databases using Oracle, PostgreSQL, and MySQL, and using the Java Database Connector (JDBC) to access them.
While Linux users (at least the older ones like me) are more used to command lines, most users want some form of a graphical user interface (GUI) to access the program and their data. Chapters 16 and 17 describe how to create a GUI using Swing and the Standard Widget Toolkit (SWT).
By far the most popular way to access programs is via a browser. Java Servlets are (maybe not so) little programs that run on the targeted web server, relieving the user of having to install an application on their local computer. This allows the user to always have access no matter which machine they're on (how many times have you complained that the program you want is on the PC where you're not?), and to always be accessing the latest version of the software (assuming the web administrator keeps it updated on the server). Chapters 18 and 19 cover Servlets and JSP (JavaServer Pages), then Chapter 20 describes Java-based web application servers (JBoss and Geronimo) for serving the servlets.
Finally, Part V covers Enterprise JavaBeans (EJBs) in what the authors describe as an almost criminally brief introduction. While it is definitely an overview, they still cover more than enough about EJBs to get you rolling, and provide many references to where you can fill in the blanks. They wrap up the book with a plea for help. The book is an Open Content book, and therefore they are requesting comments, suggestions, and patch files to help improve the text and examples.
I have to admit that Java Application Development on Linux is an extremely readable, very informative, and deep without being lengthy book. (The only complaint I have is that they tried to cover a little too much in a single book. EJBs, for instance, definitely warranted more coverage than they provided.) Carl and Michael use a very conversational tone, just as though they were sitting with you and giving you their personal attention. I found it enjoyable, interesting, and highly informative.
You can purchase Java Application Development on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Application Development on Linux is for old people. Except in Nebraska.
but python > java
-michal
AFAIK newer Java versions don't run on my Linux Powerbook. Not that I miss it.
Saying that Java is good because it works on all platforms is like saying that anal sex is good because it works on all genders.
Doesn't anybody prefer stand-alone apps? I absolutely hate in-browser applications. They're dreadful. Often slow, clumsy UI (no menus, etc.), not to mention the whole platform independence thing is a big fat lie. Consider San Jose State University, whose big stupid web database thing is pretty much IE-only. They provide a featureless and ugly backdoor for non-IE browsers. It's painful.
JAVA is a big fat marketing lie.
Write Once, Run Anywhere is the slogan, and an admirable ideal to attempt to reach.
Java's motto shouldn't be "Write once run anywhere" - it should be "Write once, test everywhere". An admirable goal, true, but don't kid yourself about what it really means.
I do some of my development in linux, and some on windows. I have found some differences in linux but very few. There is one huge advantage of java, and one huge downfall.
The advantage: Java has abstracted alot.
The downfall: Java has abstracted alot.
For anyone who has done alot of programming in Java, they will understand.
The biggest issue with cross platform development is the "Gotchas". I'd like to see a list of what is actually different between all the OSes. What os specific parameters are there. What classes are unique to Linux devices. Especially with the native IO that 1.4 and later have included.
I took a Java class a few years back. The guy teaching it was using Rational Rose and he had educational copies for everyone. At the beginning of class, we would have to wait 5 minutes for it to fire up on his laptop. He kept saying that you needed a powerful computer to use it. Itself being written in Jave, I could only help but think, "What the fuck am I learning Java for? It's a complete dog." I stopped attending about halfway through.
From skimming through the review, I saw no mention of Eclipse. I wrote a large part of my Masters Thesis in Java on a Linux machine. Sure, Í could use vi, emacs or whatever and a command line compiler, but for me Eclipse is the Java development tool of choice.
BTW. the ret of my project was Java for a HP iPAQ 5555 which, interestinly enough was developed on Windows using IBM websphere device developer, which is based on Eclipse
Freespirit
"Carl and Michael use a very conversational tone, just as though they were sitting with you and giving you their personal attention."
hm. mind reading book? and i was worried about a RFID chip in my passport...
While Carl and Michael focus on NetBeans, SunONE Studio Community Edition and Eclipse are also covered.
Editing Java in vi is one of the biggest waste of time I can imagine. Eclipse and Intellij are far far more productive environments in ways that are too numerous to describe. I think a Java development on Linux book should really ignore vi and just be an Eclipse centered tour at this point with a little bit of documentation on bash usage , scripting, deployment issues and tuning the environment.
Free But Shackled - The Java Trap
Let's see, they discuss:
* Basic Linux (files, directories, vi)
* Basic Java (two different SDKs)
* Basic software development (requirements gathering, et.al.)
* Basic programming (CVS, build tools)
* Basic Web programming (servlets, presumably JSPs, no Struts/Spring/other frameworks)
* Database programming (Oracle AND PostgreSQL AND MySQL)
* And finally, Enterprise Software in the guise of EJBs (remember: friends don't let friends use Entity Beans!)
Granted it's 600 pages, but I'm wary about how much real detail they can pack into all those topics. I'm guessing this won't be much of a reference book, but rather a large collection of introductions to a variety of Java topics.
Just junk food for thought...
I wrote a large part of my Masters Thesis in Java on a Linux machine.
Most of us simply use LaTeX, or something similar.
However said i still hate JAVA, reminds me of a PS2 emulator for DOS , dont ask me why .I fail to see why C++ is not considered code and compile on any platform, seriously GCC is available on 20+ platforms and am sure all supported and required libraries are too.
Yeah yeah binary compatibility rt ? Java is not actually binary either , has to be interpreted by the local parser .
whats wrong with ./configure , make , make install ? and its atleast a zillion times fast than java
The book seems to cover all the major aspects of Java Development. Nice and fair and all. But what makes it so special for Linux users? All the tools mentioned are available for Windows or MacOs too. Either the book has the wrong name, or the review missed some important point?
;-)
Maybe the important point is "it does not matter which platform you use for Java programming, but by throwing in some buzzword into my booktitle, I can target more nerds and make some extra bucks".
i like linux on my powerbook very much - this is a matter of personal likings, not something you can generally throw around just because YOU think something else..
well this multi-platform thing isn't real great as there's no real java-vm for linux/ppc -> IBM could at least have ported blackdown to linux/ppc.. well it doesn't matter much to me as i don't really run java apps, but probably others are affected
I know what they mean by that, but really I'd like to have open source quality apps. That's the next level up.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
While the gcj toolchain is not capable of supporting bleeding edge features, its likely you do not truly need these so the gcj baseline will also hold you to a sane subset of proven Java features.
Write once, run anywhere becomes closer to the truth if the developer has experience with multiple platforms and knows what he is doing.
Our product that runs on Linux/Solaris/AIX/Win32 also runs wonderfully on OS/390, but this is only AFTER the code base was revisited to respect that fact that a 390 is EBCDIC. For example, ASCII config files that you ship along with your distro to the 390 will be read in the system default encoding if you're using plain Readers. You'd want to use streams with an explicit encoding type. Or, just use XML since the parsers internally understand UTF-8.
So, some may say "debug everywhere" but in some cases this isn't being completely fair, if you're placing the whole blame on the JVM.
Java-Gnome binds gtk with java. Very nice.
Well, here's another article just beckoning me back to try Java development once more. Here I am, on the rebound again, not knowing any better. Almost forgetting the tough time I had creating GUIs, coming to grips with the AWT then Swing. Going nutty putting multiple classes in a jar file and all that manifest destiny sweet talk that had me at "hello world" but not much further when I ventured out past the simple stuff.
.NET, but too afraid to jump head-on into a relationship with cpp.
Oh yes, it was sooo much better than VB if you can get past the quick way to make graphical interfaces. The multi-threading made creating a multiplatform port-scanning tool so much more pleasurable.
Then there was running the code on multiple platforms. The need to install the JRE, ensure you're pointing to the right CLASSPATH, and all those somewhat cumbersome things.
Yeah, after a while, I forget those experiences. I come crawling back, not wanting to be assimilated in
I'm sure it's going to take time and effort, and I know I need to put more time in our relationship. Right now, though, I'm in the middle of a project with PHP so I'll get back to you when I can. Just remember, Java, that it's not you...it's me.
P.S. -- I think your father's a prick.
How well is Java supported under FreeBSD? I'm not quite familiar with FreeBSD, but a friend of mine keeps saying he has a lot of trouble with it while using FreeBSD. Especially getting Java to run in his browser. Is this true or is he just a dumb ass?
...if this book was about any other language ever invented it would be 50 pages and 10 times quicker to read with 90% less calories burnt?
I congratulate you on providing one of the best examples of trolling I've seen in a while from a non-anonymous post. Let's see if you've covered the basics:
Congratualations... you're a winner!
All sarcasm aside, if you don't like Java and don't develop software in Java, then a book whose title starts out Java Application Development is probably not for you. Moving right along....
I think he meant he was sitting in a cup of coffee that was sitting on top of a Linux machine.
They liked Visual Basic, a lot, because it allowed them to hire dum-dum programmers, who were, most importantly, cheap. But it only ran on Windows, so Java was invented. If MS had ported VB to Linux et al, all you mediocre programmers would be VB'ers.
Actually, this book sounds like a good idea - cover deployment issues like database installation and configuration with Java, tips for deployment, etc.
:-) would make Java a more suitable language for small applications and utilities. This would get around Sun's lame Linux/Java licensing issues also.
I usually do my development on OS X (except for new JDK 5 coding - use my Mac as an X display for a Linux box -- annoying that Apple is slow getting JDK 5 out except for in a $500 developer's preview). Anyway, I do most of my deployment on Linux, and the ease of this depends on which hosting company I am renting a server from. For example, is a usable (i.e., PostgreSQL) database installed, easy to administer, etc. I have not read the reviewed book, but hopefully a lot of practical issues are addressed.
One interesting thing about the Linux platform is that now all new distros have RPMs (or equivalent) for installing runtime and developer support for GNU GCJ.
I find GCJ to be very interesting (a bit of a nuisance to run on OS X) because not only is it a way to run Free Software (GPL) on Linux, but it also makes it possible to take large Java applications like Lucene, compile them natively, and then use the compiled code in Python, C++, Ruby, etc. programs. Very cool, really.
If Linux was my development platform, GCJ would be a much more important tool for me - it would be great if Apple installed GCJ runtime libraries by default (yes, they are large). While Java is not as productive a language for many programming projects as Python, Ruby, etc., Java is a great language and platform for many types of projects; having GCJ runtime installed by default on OS X, Linux, and Windows (well
I'm not a Java zealot by any means, but Java deserves credit for what it does well and one of those things is reducing the importance of platform.
;) -- that runs on XP, Redhat, Mac/OS, Solaris >= 8, HP/UX and AIX 5L.
I've recently worked on a J2EE project with nearly 1 million lines of code -- they're all needed, really
Have there been platform related bugs? Yes.
Are there any open? No.
Are there some lurking? Maybe, but we've tested extensively.
Could any collection of jackasses build this app? No, sorry.
Is Java a magic bullet? No more than any other tool.
I won't argue that Java feels a little bit slower than C++ on a native platform. However, there are a few instances that I can think of where a developer would choose Java over C++:
.NET, you couldn't easily code the interfaces. At least with Java you can guarantee everything will look the same no matter where it runs.
Portability - You can't run C and C++ in a web browser very easily. In an enterprise environment, or even on the internet, you need to be able to distribute your application quickly. No one likes having to download a program from the Internet, especially in the days of spyware and adware. Allowing people to just run your program with code they know won't break their computer is the best way to fly. No to mention, HTML allows you to embed a Java applet much easier than CGI allows you to execute a local program, in my opinion.
User Interface Design - Ever try to write a Windows interface? What about a GTK interface? If you need a program whose main focus is in computation and calculations, not User Interface or data entry, an IDE like NetBeans will help you easily design the interface in an hour or two rather than having to manually code it by hand and constantly test how it looks. Before
Memory Protection - With Java, you have no worries about memory troubles. With C and C++, the developer has to handle his own memory allocation and garbage collection. Java does it automatically. What worries do you have when you dereference a pointer to 6 MB's of memory if Java is going to clean it up for you? There's almost no room for pointer miscalculations and for dealing with ugly Microsoft API's that handle six or seven different arguments, all either reading or writing and all being pointers. Unix API's are simpler but you still run into Segmentation Faults with Linked Lists and other Data Structures.
When you write an application, you want to focus mostly on the purpose of that app, not small CS details such as memory allocation and UI design. Obviously, some projects require this attention but for an enterprise project that isn't going to break into any new territory, eliminating as many problems as possible is the best choice. That's why languages like Perl and Java are great - very little chance to blow things up. I'd agree with someone that Perl might be a better choice in some instances over Java, but saying that C and C++ are better choices because you can compile them natively and run them a few milliseconds faster isn't a good reason for me.
I use Xemacs, JDE, and make on Linux to create commercial products in java/jsp.
At my last job, back on 2002, ant forced me to hate it when:
1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
2. We had this crazy huge build.xml file that was created for our project. It started off life as a rats nest and only got worse from there (OK, probably not ant's fault but it had the same effect on me). On top of it being huge, its in XML which is way hard to read compared to a makefile.
3. I never could figure out how to ask ant to echo the compile line. Make echos it by default and I like it that way.
That was three strikes.
On my current project we are using make but one of them whipper snappers came along and made a build.xml file for the project. Its just one big, ugly, build.xml but it is much faster. The project has 30 or so small, easy to read/understand, makefiles (and I figured out how to make it go much faster on a clean build but its still not as fast as ant).
Sure, make has its quirks (e.g. the tab thing) but I figured all thouse out 15 years ago.
I tried Eclipse last fall after seeing an interesting presentation on it. I tried it for a couple of days but it felt so bloated that I soon abandoned it.
This sig intentionally left blank.
I find that I use the same tools on windows and linux for java development. Ant and Eclipse, they work about the same.
My Weblog
Eclipse is just plain annoying. Behind the pretty shiny interface is, well, just an icky IDE. Oh, it's modular and open source. How nice. Heck, with software written in Java, it's almost impossible to write something that isn't modular. I'll take the sanity of IntelliJ IDEA, thanks.
I was quite happy that the folks over at Jetbrains had a nice $250 personal license special a few weeks back. It's the only decent IDE I've used.
None of the topics mentioned in the review really seem to be Linux specific. Why not just call it "Java Application Development" (period, no "on Linux")?
There are some things that I think would be worth covering though, in a book about Java/Linux. Particularly for someone coming from a development of an app in a Windows Environment to deploying an app in a production Linux environment. Since often they will know all they need about Java. But won't be very familiar with Linux. And may not know the best way to do things in a 'Linux' way.
Some examples...
Init Scripts: Setting up init scripts to stop/start your Java services (e.g. getting tomcat to run on boot up). That differs a lot from how you'd do it with services on Windows.
Permissions I: Often on windows things will be run as root/Administrator. On Linux the better way is to have Java services run as a non-root user. e.g. run Tomcat as tomcat not root. There are some implications to this. e.g. you an unprivileged user cannot listen on addresses with sub-1000 port numbers. The solution is something like iptables or mod_jk2.
Permissions II: Another permissions issue (that I see crop up a lot with people moving from the Windows dev machine to one of our Linux servers for productions) is file permissions. Users being not being able to read/write config/data files that they had been able to see/use well enough on Windows. i.e. a paragraph on the almighty chown -R would be handy.
Command Lines: A page or two on running things from the command line would be a great thing. Often people working on Linux servers are doing so remotely. And won't have a GUI. And often they are only familiar with launching their app from the ide. So knowing about 'java' and 'javac' would be handy. And mention the need for colons between dir names not semi-colons. e.g. java -cp /myclasses:/3rdparty.jar mainclass.
Automating Tasks Users moving from a windows/dev environment to a Linux/production environment would also be well served by a page or two on automation tools. e.g. using ant to automate the process of getting code out of CVS and deploying it. e.g. cron for automating the process of running Java jobs on a regular basis.
--
Java Hosting on Linux, Simple Enough Even For Windows Users
Look at http://brutus.apache.org/gump/kaffe/
This is a nightly check out and build of all OSS projects in Gump. It is slowly coming together, as now the projects are putting in tweaks to work better with the kaffe toolchain, pulling out any naughty use of sun.* code, etc, etc. The goal is simple: all the Apache and other main OSS projects, built with OSS libraries, on an OSS JVM. One day, we shall be truly free...
that's all.
"The new wave is not value-added; it's garbage-subtracted" - Esther Dyson, Dec 1994
a "write once, compile everywhere".
If your program _only_ relies on gcc it must be a text-based app - X calls don't work on Windows and MFC libs aren't available for Linux.
Java comes with portable GUI libs.
Slashdot's name? When my compiler sees
Parent post is probably as balanced as you will get on /., I think he sums it up: Java is 98% problem-free cross-platform, if you poke long and deep enough you might find some problems, but these problems are most usually minor and mostly due to slightly different underlying platform issues like threading models that give different scaling behaviour (cross-platform doesn't mean you can entirely escape the platform you are running).
For me, I'll never miss copying and pasting between two files by doing:
:.,+6w /tmp/ken1
:r /tmp/ken1
ma to mark the start of the block
j as many times as it took to get to the end of the block, counting in my head as I go
'a to return to the top of the block
Then in another window, or after exiting and running vi on the second file.
move to where you want the block of code
That is so much faster than Copy, Paste.
I used vi for years. Then I leared emacs and enjoyed the directory navigation and being able to have lots of files open.
JDEE is not to bad for java in emacs.
But after starting to use Eclipse, I hardly ever write code in emacs and never in vi.
YMMV
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
"It's a real eye-opener to load up your vi-edited code into Eclipse and see the cruft"
What's a an eye-closer is looking at the code that comes out of Eclipse in vim. Even the indentation is screwed.
I did not say you were required to use GCJ, just limit yourself to the subset of Java lang and libs that can be *compiled* by gcj. Last time I checked and recent Sun javac/java combo should be able to handle this....but when they do something you really don't like, you know you can fall back on a free option for compiling (note that *any* recent Sun JVM will still be able to run the code!)
Commercial quality is "High enough quality that someone would you pay for that and won't be pissed."
Does that describe the Windows XP operating system, a competitor to GNU/Linux that is proprietary and commercial but nowhere near high enough quality out of the box or even as patched?
Java over promised and under delivered. It's not difficult to find programs that will decompile Java byte code back to readable Java code. That means your source code can be difficult to protect. Because there are so many different virtual machines, you can't be sure your app is going to work properly unless you are able to strictly control what the user installs on their machine. Finally, if you want a native UI, you end up writing code that is no longer cross-platform. Where Java does work well is on the server where you can control the environment and don't have UI to worry about.
A better solution to building cross-platform client apps for Windows, Linux and Mac OS X, using an object-oriented language that basically provides all of the advantages of Java without the negatives described above, is REALbasic. . Now before you say BASIC? Why would I want to use that? This is a fully-compiled, object-oriented BASIC that is as OO as Java but creates native applications. It's really what Java should have done but didn't. Anyone that seriously cares about cross-platform but has been frustrated for one reason or another with Java, should take a look at it.
I've talked to Java developers that have ported their client apps to REALbasic because of the problems I mentioned above and their are very happy with the results.
Perl is more portable than Java. Probably by at least one order of magnitude. No joke, go look at the Configure.sh script that comes with the Perl src. You'll see archs in there you never even heard of before. Java is just a sad joke in comparison.
A better way to copy paste between files in vim might be:
:new otherFile.java
:wq
yap
(position cursor)
p
or in an ide:
drag a box over the paragraph
control-C
find other file in an enormous list of code files.
double click to open
position cursor with mouse and scroll bar
control-V
mouse to file dropdown, click (save)
click on little x to close file.
Seriously...if your machines don't run Java in a snappy fashion, it's time to give up the Pentium2s and buy some modern hardware.
I'd rather spend less time developing and a bit more on resources, than cheap out on the machines and spend hours and hours optimizing.
Blar.
The worst thing about Java, supposedly a "write once run anywhere" language, is that you can't run anywhere. You can only run on platforms that Sun has ported a JRE to. This is why projects like Kaffe are so important. With an open-source implementation of the Java specs, you never have to worry about unsupported platforms or Sun yanking the rug out from under you.
Constitutionally Correct
Only in slashdot could a person read the following statement:
Anal sex works of both genders but you don't like anal sex at all.
So I have a friend who worked for Big App Server company a few years back, when J2EE was just startin to break big.
He went in for his first day - he was doing tech support - a guy comes up to him and says "dude, here's your first case, I sent it to your email". So my friend opens the email, downloads the file to the drive root and then proceeds to drive the mouse 'till he finds Visual Cafe. Needless to say he can't find it and the guy is looking at hime thinkin 'what the hell?!' and tells my friend "dude, what are you doin? Move over."
He kicks my friend out of the chair, opens up a cmd (yes, it's Windows) window and types:
emacs filename.java
he gives it back to my friend and my friend kinda stares for a sec and says "what's that?"
"Emacs. And it's what we use here."
Then the guy walks away. My friend called me up that night and said that was the hardest working day of his life.
I think there's a certain art in editors that don't have a lot of icons and menus. So for me, it's always been about emacs. I also know just enough vi to get me by on whatever *nix machine I run across.
Never use IDEs but a lot of people love them. Sorta like favorite ice cream flavor. Would I use Eclipse/NetBeans if I had to on a job - sure, but I wouldn't necessairly enjoy it (that's happened a few times).
I think it's easier for developers to go from text -> gui development vs. the other way around. My friend was the perfect example and I've found that while on client sites, when I got to use Emacs, people would fumble quite a bit at my desk. But when I went to theirs, there usually weren't any issues.
Plus, while I'm all for machine intelligence, there's just something about knowing all the pieces of your code and putting them there yourself. Yah, it takes longer, but when in a bind, I've seen a lot more IDE/code-completers fumbling around with errors or whatnot vs. their emacs/vi/shell countrerparts.
Just my experience, yours may vary..
The time of one programmer is not as important as the time of thousands of users who have to wait while your JAVA application grinds the hard drive and flips the hourglass endlessly.
In vi (and most shell apps) control-z returns you to the shell, and suspends the application you were running. This leaves you free to run other applications, like perhaps:
ant devbuild
watching them complete, then returning to your suspended ap with:
fg 1
-Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
Seriously. Was the Earth invaded by blind-brainless-dorkies?
Oh crap. Java is nothing but hype! Fuck.
A fifty thousand lines Kylix program compiles faster than a "hello word" servlet is deployed. And executes 5 times faster.
With all this "VM" and "run everywhere" bullshit instrumentation isn't any better than it was 10 years ago. All the performance problems and missing features persist.
Oh fuck. And why that crappy C syntax? And stupid "virtual by default" methods. Give me a break.
You all go fuck yourselves.
Servlets are not programs that run in a web browser, they run on the server. Applets are the programs that run in a web browser. And I don't think servlets are generally considered to be "little", though applets probably are.
Moderators: Please note that "bonch" is a known fanatical psycophant whose obnoxious offtopic rants are legend here on Slashdot. It doesn't matter what the topic is, he'll find a way to scrape in some pointless Microsoft shilling. While nobody expects us to love Microsoft in any way, his particularly tepid style of calling anyone he replies to "troll" or "liar" because he happens to disagree with whatever they're saying is well documented and should not be rewarded. If anything, bonch is the type of person that should not be part of the open source/free software community. He is an anathema to all that is good about free software.
/. subscriber, I invite you to look through some of his posting history. I guarantee that you'll be hard pressed to find someone that is more "out there" than bonch. You'll also probably notice he's got quite an AC following. Don't just read his posts, make sure you go through the replies.
I'm posting this so that you (the moderator) have some context to consider bonch and not mod him up whenever he posts his filler preformatted rants about installing Windows or whatever that unfortunately get him karma every single time and allow him to continue posting his trademark toxic crap (read on) day in and day out. You may consider this a troll - I consider it community service. And I ain't kidding.
If you're a
For example, in this recent post bonch not only calls the OP a troll but attempts to "tell it like it is" while making some vague argument about "MS". Yes, if you're confused, you're not alone. The reply (modded +0) proceeds to simply destroy his bogus argument. You will notice he did not reply. This is what some people call "drive-by advocacy". A sort of I'll just leave you with my thoughts here and move on to the next flamebait kind of deal. In fact, he almost never replies because he knows that his fanatical arguments simply do not hold up to any sort of discussion. It's not that he's chosen the wrong cause - he's just going at it in a completely wrong way.
More? Just read though this post and the subsequent replies. I guess this stands on its own.
More? Bad spelling in astounding conspiracy theories, more offtopic FUD and uninformed "I'm right, look at me" rants, promptly proven wrong. Worse even, bonch wants to be Bill Gates, apparently (that first one is a winner). I mean, really. You think?
FUD, FUD, FUD, FUD, offtopic FUD, and more FUD. This guy is like the Monty Python SPAM skit, but with FUD and more FUD instead of canned meat. Amazed yet? Don't forget that KDE and Gnome make you dumb, and it's all a Slashdot conspiracy. How low do you want to go? Maybe as low as this?
The infamous Slashdot Front Page Troll? Nuclear fireballs? It goes on and on and on and on and on and on and on (troll?). Like the energizer bunny. Or take these two, which stretch the definition of weird.
It's up to you. We can get rid of this guy and make Slashdot a better place. I don't know about you, but I'd rather take the trolls and crapflooders over people like "bonch" any day. And I sure as hell don't want to be categorized along with him. This is not how you advocate free software, period.
a book that is a complete guide to writing commercial-quality Java programs.
Chapter 1: Confusing the user.
Chapter 2: Meanlingless error messages
Chapter 3: Remaining slow no matter how fast the hardware is.
Chapter 4: Losing data.
And finally:
Chapter 5: How to create the blue screen of death.
No thanks, I've had enough experience with commercial-quality software.
Show me. Show me a non-trivial example where this actually happens and I might start taking anyone who says this seriously. So far the runtime overhead has far outweighed any supposed benefit from being able to tune things at run-time. And let's not forget that there is such a thing as a profiler you can run to generate an execution profile and put that into the compiler along with your program to generate even better code. It won't adapt at runtime, but it can provide huge (measurable!) speedups.
(Not the original poster, I actually do understand that JIT != Interpreted byte code
Yeah, show me a website powered by Java and I'll show you one slow ass website. No big websites use Java. Yahoo, MSN, Google, Dell, eBay, CNN. Imagine Google trying to use Java....lol. -Nazz
e cent/eb ay_5.html .NET in favour of Java
9 3666433 000.htmlr ticle.pl?si d=04/11/19/1618217&tid=105
You have clearly been misinformed:
eBay uses Java:
http://www.sun.com/service/about/success/r
They actually dumped
Google uses Java:
http://www.ccombs.net/weblog/2004/08/28/10
They were even part of the JCP (Java Community Process):
http://eyeonit.itmanagersjournal.com/a
Yahoo uses Java for their sitebuilder and chat, among other things. Don't know what they use for the main site but it wouldn't surprise me if Java was in the mix somewhere.
MSN:
Gimme a break!
CNN does use java in a limited way:
http://sportsillustrated.cnn.com/java/
If you still think Java is slow pay a visit to EBay and check out the number of transactions they process in one hour.
that is as OO as Java but creates native applications.
This is completely losing one of the most important aspects of Java - the ability to choose the platform on which you deploy code after compilation. For example if I make a J2EE application, I can open a web interface to Tomcat, and deploy the application. I don't know or care what operating system Tomcat is running on. Why should I have to? Why should it be up to me to maintain compiled binaries for each operating system?
Actually the old symantec slogan is:
Develop once, debug everywhere.
Though I think they meant something else when they adverticed their new debugger for java...
gcj (gcc java compiler)
SWT - Standard Widget Toolkit ( either from eclipse.org or libswt)
Same difference, write in Java once, compile for each architecture with the appropriate SWT library. Compiles to native. (Azureus is an example that pops into my head.) If you like the other features of Java, but don't like the JRE and having your users have to setup java to install your program, this is a great solution. Java still may have its limitations, but write once run everywhere natively is not one of them.
All of my classes are taught in Java, so granted I don't have in depth knowledge in C++, but it seems that most things can be accomplished with most languages. In other words, the real limits of most programming languages are less than the perceived limits. I will admit that I would like to learn C/C++ better for system programming.
Where is my openbsd/alpha jdk? Oops, there isn't one. But Perl, python, ruby, pike, C, C++, ocaml, lisp, etc all work fine. Yeah, looks like java's really kicking ass in the write one run everywhere department, unless you actually mean everywhere.
I wonder how Java's apt will mesh with Debian's one.
Where platform issues become very important is when you are doing multimedia. Sound and video on Java just won't go without HEAVY native support - and on Linux it's a real rats nest of native libraries and versions and open source tools required.
So where's the discussion on that!!?? Seems like a major ommision.
Also, how about filepath and classpath separators? Native installers? vs. ?
Something we hit HARD was the difference in TCP/IP timeouts between the Linux and Windows TCP stacks.... so uh - any discussion of that? I didn't see it in the review.
In Soviet Russia, lamerisms beat you!
You can hold down the "B" button for continuous firing.
For some reason, I hope she didn't see that.
You can hold down the "B" button for continuous firing.
Oh that's rich, someone is hounding Bonch who spends much of his time spewing bile here on Slashdot and never contributes anything useful. I'd love to be able to read and converse about free software without people like Bonch getting in the way. You are free to use crap that has owners the can turn you off at their pleasure, but please go away from here.
Let's go back in time and look at some of the M$ love fest, apologizing and Slashdot insulting from Bonch:
All of the above was found by looking at two pages of google results for bonch slashdot. More than half of the results were like those.
Well, that's enough fun for me for now. Thanks for playing, Bonch. I hope your account is deleted soon.
Friends don't help friends install M$ junk.
theoretically maybe, but not in real life