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.
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.
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.
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
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...
Exactly, OSX was designed for UNIX not LINUX. How can you even think about using LINUX on a powerbook!
I wrote a large part of my Masters Thesis in Java on a Linux machine.
Most of us simply use LaTeX, or something similar.
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".
*sigh*
I can't remember the last time I had issues with code because I changed platform, OS, or even JVM version. It's to the point where I don't think about it anymore.
Maybe if you're talking GUI code (desktop/applet), but for web or backend it's just not been an issue for me in some time. I've been developing on Java professionally for nine years now, and have have production systems in place for eight. I remember when you used to need to test every single VM, but by and large that time is done.
For example, I just finished working on a project running on J2EE 1.2 on Websphere 4 (jdk1.3.1) on Windows to running Websphere 5 (jdk1.4.1) on Z-Linux. The *only* thing I had to change was code that was written out of spec (a few JSPs forgot to import java.util.Vector). If the developers of the app hadn't been sloppy, there would have been no code change at all. This is an app that hits databases on Oracle, DB2, Teradata, and LDAP (with updated drivers for all of those, too).
I can think of plenty of counterexamples, but for most server-side business apps it really is write once, run anywhere.
Your binary gets interpreted by the local parser too. It's called a CPU.
./configure, make, and make install? Simple. Not everyone wants to distribute source code. Shocking, I know.
What's wrong with
I don't love Java. All things considered, I don't see that their efforts at cross-platform compatibility are really a big win over things like the Standard C Library. In both cases, you have a language and a supposedly cross-platform standard set of library calls, and in both cases you end up having to code around the quirks of the platforms you run on. I think the right place for Java to have targetted, the place where it could have been the most useful, was as a client-side platform-indepedant environment, ala Applets in the web browser and whatnot. Unfortunately all the effort went into perfecting a server-side environment instead.
11*43+456^2
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.
Sure, you have to test on all the platforms that you support. But, what language/runtime requires less x-platform testing than Java? Today, the real issue is testing on each J2EE app server. That's where the real issues are. I haven't seen a pure Java platform issue in years.
This is an old joke from 1998. In my experience, I have rarely found a problem and I regularly code and compile in OS X or Windows and deploy onto Linux servers. The one area I always have to be careful about is setting up the AWT environment, but this is sysadmin stuff and does not effect the code. What experiences have you had (since 1998) that lead you so say this? Probably in GUI apps, where I do agree. Everything gets tested on Windows, and looks like utter crap on a Mac. Except Eclipse, of course.
"Write Once, Wait Forever to Run Everywhere"
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.
(Just as a side note, the weirdest porting problem I had was the result of someone who shall remain nameless assuming that all filesystems are case-sensitive. I unpacked the source tar onto an HFS drive and spent ages trying to work out why some externs were undefined. tree.c was being extracted over TREE.c. There are so many assumptions one can make without checking that they hold for every platform - and even if they do, a future platform may break them if they're not part of a standard to which you're working).
Java-Gnome binds gtk with java. Very nice.
Why do I keep having Java applications that require a specific JVM level. Not just a minimal level but an exact level. I am running 3 different JVMs on my workstation because of this. Is this just sloppy programming on someone's part or what.
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.
That is exactly where they initially promoted it, but AWT performance was terrible and few had the broadband to download the jars in a reasonable time. So focus moved to the server side, where it performed well. Now, IBM has built native SWT widgets and performance is not as bad, although still a slow start and a monster memory hog for GUI apps. The best thing about Java now, as with Linux, is the enormous community of developers building excellent libraries (jakarta, hibernate, spring, webwork, etc). That is where it truly shines.
I had no trouble with recent JDKs on Debian 3.0. Your powerbook must be the flintstones model.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
> JAVA is a big fat marketing lie.
Which, amazingly enough for a lie, I am now using to rewrite some of our inhouse utilities in preparation from the move from Win2k to Linux servers. There's not too much overhead on CLI Java programs, and I've ported one app so far, rewritten on my Windows box, and it ran without a single hitch on the Linux server it's destined for. No recompiles, no nothing.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Sloppy programming and / or paranoia by the developer.
Anything written for java 2 (1.2 and up) should work fine on the latest 1.4.x, and will probably work fine on 1.5 (I have had some funny issues with 1.5, but they were build time issues)
The only thing I've encountered that actually broke stuff in a version change was the bizarre choice by Sun to not just deprecate reading the OS environment, but to completely disable it by causing it to throw a runtime exception in 1.4 They changed their mind and re-enabled it and un deprecated it for 1.5 though.
Advanced users are users too!
Sorry about that, _Powerbook_ didn't sink in right away.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
...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 work for a fairly high profile Internet commerce company that uses WebLogic and pure Java. Our production servers all run Solaris, most of our developers run Windows XP (previously Windows 2000), and I run Linux.
We have hardly ever had any issues with "Write once, run everywhere." It works. Really. Probably writing Swing/GUI apps is different, but on the server side, developing and deploying across different platforms works like a charm. Admittedly the issues you get on development vs. production can be very different, so deploying a production system on multiple operating systems might give you different results. But as far as testing and developing on two platforms, then deploying on a third, we have no complaints.
In a real emergency, we would have all fled in terror, and you would not have been notified.
Mebbe, neither does anyone else for making your post about what i cared or did not care.
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....
If you seriously can't see the difference between having to run "make install" (oh, and good luck if autoconf didn't get things right) and "java -jar myapp.jar" you have never developed an application worth the name.
As a troll though, congrats I guess.
Which linker? Which version of libc? Linux or UNIX headers?
C is technically the most portable language ever, but it doens't make it trivial. People say "test everywhere" as if that's supposed to make Java look bad, but I think it is a god-send relative to hacking up the C preprocessor and figuring out autoconf.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Of course theory and practice are still 2 different beasts.
Why, oh why, didn't I take the Blue Pill?
I normally don't reply to "Anonymous Cowards" but in this case I will make an exception.
If you are running OSX 10.3 you are running a very new version of the JVM. If you are running OSX 10.2 you are also running a very new version of the JVM. So I guess my question is what OS are you running on it?
Now you mention that you don't "miss" Java. I will argue that you don't care what an application is written in, as long as it looks good, is stable and does what you want. So I challenge you with this. How do you know what the application was written in? You probably don't. If you are a Linux/Macintosh/Windows/Netware/Solaris user and you launch your MP3 player and it works do you really care to see if it was written in C, C++, Java, Cobol?
JAVA runs on all MAJOR platforms.
It doesn't require the user to "compile" any code to run.
It has a rich GUI toolkit built in.
It handles object cleanup well.
It's speed has become excellent at most tasks
It has excellent networking support built in.
It has a giant developer base helping to add funcitonality.
The more I learn about science, the more my faith in God increases.
Actually, Java byte code is not interpreted, and has not been for some time. You are running just-in-time compiled code. This means startup is slow, and memory is hogged, but don't claim it has to do with an interpreter.
I think he meant he was sitting in a cup of coffee that was sitting on top of a Linux machine.
The sad part about this is that someone might actually give you a job someday to do something that involves programming when your real calling is at the CBS News department.
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'm a starting (as in: learning) developer, and my platform of choice is linux. I write mostly in C. So if I compile my stuff with in elf format, it'll run perfectly on linux 2.4.26 with glibc 2.3.2 and the likes, but thats about it. Now if I however compile it with gcj (which works perfectly), I can share it with all my friends with much rejoice :-) I can actually get feedback from my windows-using friends.
Now please convince me java is good for nothing.
The thing about java is that everyone is forced to distribute "source", or more specifically, bytecode, which amounts to the same thing for cross-system compatibility purposes.
Can you make non-portable "libraries" in Java? Yes.
But making (and finding) portable "libraries" in Java is much easier.
Did you buy a Neuros today?
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.
Ok what have you developed in JAVA that has caused you problems on other platforms? Could you give some specifics? Perhaps I do boring code, but I have developed many many many many many java applications and have had little issues moving from:
:-) The language isn't perfect, but for a lot of us it is by far the best language out there.
NetWare 5.x
Windows NT
Windows 98
Windows XP
Windows 2000
Solaris 7-8
Linux (various versions and distro's)
Linux 64 bit (SuSe for X86-64)
IPAQ (small apps, not much experience)
Palm OS (again small apps not much experience)
Macintosh OSX 10.2 and 10.3
and i am now looking at the Nokia cell phones.
I have not found any Major issue with any of those platforms. Granted I just do business applications, and don't make games, so perhaps I am missing something.
I, on a daily basis write code in Windows/Jdeveloper and then deploy to a mid tier running JBOSS/SuSe 64 bit, then deploy to production of both RedHat and SuSe 32 bit running both JBOSS and Resin. For me JAVA has achieved write once run anywhere. We still do test, but I can't honestly think of any issue that has been because of some JAVA incompatability on a particular platform. Are there quirks with different JVM's??? Yep, but I have found that to be the case on the same platform
The more I learn about science, the more my faith in God increases.
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
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.
1 MegaLOC. 36 megs of Java source. Swing, JSP, Servlets, SOAP, SOA, Kerberos, LDAP, JDBC, and EJBs (to name just a few). Our newest clients are C#. 4 years I've been working on it. I'm one of 4 developers using Linux. The other 20 or so use Windows. We deploy to Windows 2000, XP, Solaris, SuSE, Debian, and RedHat on the server side, and all those but SuSE and Solaris on the client side. The most I've done to support it is replace backslashes with forward slashes (forward slashes in Java work on any platform).
Stop propagating your ignorance.
Stop-Prism.org: Opt Out of Surveillance
A few (who am I kidding... several) years back, Gartner was promoting a different spin on why IT departements should adopt Java: "Train Once, Write Everywhere". The idea being that with Java, you could have (in theory) the same guys who are writing the GUIs and desktop apps write apps for the server and mobile environments too.
Yes, I know you could argue that "C" fits this bill nicely, too, but the fact is that most corporate IT shops at the time were VB and PowerBuilder clients talking directly to databases. Your average corporate developer would do more harm than good with C, and Java was seen as a simplified C++.
Anyway, I don't know if Gartner ever changed its stance on this, but the reality became quite different with the introduction of J2EE; J2EE required quite a different set of skills compared to good ol' J2SE, and many developers still can't adequately grok distributed server-side development.
Java is just a language, and I firmly believe that more attention needs to be given to the art of programming rather than to any specific language. It seems nobody cares anymore for appropriate use of patterns and careful selection of algorithms. It's all brute force programming. Get it done. Here's your soup - go code.
You can learn all the languages you want -- learn to speak English, Russian, Spanish, French, Hebrew, German and Greek -- but if you don't know how to communicate...
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
If you seriously can't see the difference between having to run "make install" (oh, and good luck if autoconf didn't get things right) and "java -jar myapp.jar" you have never developed an application worth the name.
I think that's also a bit more than flame bait. I'm learning both C and java. C is lower level, but at least I find it easier to write and read. And I don't have to worry about classes, filenames capitalized, commands that are extremely long and have so many "." and other weird things going on.
So don't insult other people like that. I'd rather do a make install for a program that'll use the gtk interface like the rest of my system than do java -jar myapp.jar and have something that is totally off and disturbs the eye flow on my desktop.
I'm sorry, but I'm picky enough to do this. If you're not, it's your problem, but don't yell at others for wanting something smooth.
---- I am certain of only one thing : I know nothing else.
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...
I try and compile your code with GCC and get tons of errors. (I get them all the time with Linux and so do you if you grab lots of source code, perhaps this was the core reason RPM was developed). You and I then spend lots of time working with people to resolve the issues. We generally find out that we don't have a recent library that is needed or we find out that we have too new of a library. We then have a fun option of going to "RPM hell". We start a long process of upgrading stuff in hopes that it will fix our problem.
Some of this is the same in JAVA but with one difference. You don't compile the source code on the machine. You send them a JAR file (zip compression) and in most cases they can just click(or double click) on that file and it runs. Doesn't that sound better? Send a file to a user, have them click on it and it runs? Heck you can even do one better. You can use Java's web start and have them go to a web page, launch the app from the page, it will check to see if you need a JVM installed, if so it will install one (major platforms only), then copy the application down to you and run it. The next time you try and run the app it will check the server automatically for updates and download them if needed. If for some reason the network is not available then it will run the local copy. Some people hate this, but a ton of developers and businesses love it. So now you have two ways of delivering your application. One with Webstart and one with sending a JAR file. No compile needed on either one. All the user needs to do is click on the file and they are off and running.
Lastly, I would also argue that if you have some basic users out there it will be far far easier to get them to load a JVM(with or without using webstart) than it is to get them to load a C compiler. The JVM installer has come a long way on all the major platforms.
Again though I ask you. Do you really care what the code was written in? When you click on your Instant messenger, Email client or CD/DVD burner and it runs, do you care what it was written in? If so then why?
Now I as a developer who wants to write a DVD burner have three options.
I only target Windows because they own 93+% of the desktop market? Most will answer yes to that question and use only Microsoft stuff, and lock the app in to the Win32 API set.
I can develop the application in JAVA and make the installer check to see if the user has a JVM installed. I then can focus my testing on Windows and the product should (without recompile) run on all other platforms.
I could write the software in C or C++ and force the user to have a compiler for their system, (good luck on the various windows versions), then compile the code on that system, create icons for them and they would be off an running.
Out of those options most developers choose options 1 (sucks but it is reality), a few pick option 2 and only open source people pick option 3.
lastly I want to point out that NOTHING is stopping the developers in option 1 or 2 from giving the source code away also. So those brave souls who wanted to compile it could. I can say that I run a quite a few JAVA applications from sourceforge that were written soley on Windows and tested on Windows but because they were written in JAVA I have had GREAT luck in getting them all to work on Linux. Specifically 64bit SuSe. Now getting C source code and compiling it.... Well that is another matter. I still don't have a working copy of Mondo, and can't compile it to save my life.
The more I learn about science, the more my faith in God increases.
Back when I was running JDK 1.4.whatever, there were inconsistencies in operation between Windows and Linux using the NIO (non-blocking I/O) libraries. There are several messages on Sun's message boards relating to this. It seems to have been worked out by now. NIO was kind of squirrely for a few revisions there.
I have coded a wide range of applications, and have used many of the facilities provided by Java. NIO was the only part of the standard library that gave me trouble. However, I have a friend who was using Java3D for a project. His jobsite uses pretty much the gamut of operating systems. He has told me that Java3D is just plain not portable. Code that worked on Windows would not work on Solaris. I have no details on this, but they ended up using something else, according to him.
Java isn't bad because of issues at compile-time on different platforms. It is bad because you simply can't trust a JRE to install automatically (newest version) and run a given Java JAR. Sure it runs if you specifically handcraft the environment on each computer but that doesn't save anyone important (developers are not important in this case) any time.
Linux is not Windows
Almost any modern programming language can get you platform independance if you just use Sockets, File-Access and "internal" logic. Server-side programming doesn't use many platform specific libraries.
Linux is not Windows
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).
I guess I'm talking about server deployment for web apps, since that is what Java is mostly used for. Thus, I called it "sysadmin stuff" since the code is not affected by it, nor could code in any language magically avoid deployment and system maintenance. I have deployed Java GUI apps, and believe me I spent plenty of time on the installer.
Thanks for the input and you are correct about NIO, and the 3D API's. The Java NIO API's are relatively new and from what I have read, have improved a lot. Now as for the JAVA 3D API's... I believe that does require OpenGL to be installed. So your friend is using an API that requires another API to be installed. That in and of itself sounds dangerous. Yes it should work, but heck how many times have you needed to load a newer video driver on your Windows box just to play the latest OpenGL game. Companies like ATI don't support OpenGL near as well as say Nvidia, so that also could be some issues. His problem may have nothing to do with the JAVA API's so much as video driver issues. Then again the Java 3D packages could suck, I honestly don't know. I will say that I envy your friend, he is getting to code some cool stuff.
:-)
Again thanks for the input, but I still stand by my point that 99.999% of standard business applications will work great with not mofications to the code.
Lastly thanks again....
I have a new skunkworks project that needs to use JAVA's NIO package and needs to run on Linux/Solaris/Windows, so I will proceed with caution
The more I learn about science, the more my faith in God increases.
Too true, I used to develop a web app and used Solaris/sparc with Sun's JDK 1.3.1 for my dev server and then deployed on Linux/intel with IBM's JDK 1.3.1. Never had a problem.
The GUI issues seem to be limited to areas where you bunt up against a platform limitation. Like using second/third mouse buttons on a mac, or failing to use the File class properly. They are usually self inflicted. The only real issue I ever had was with drag and drop flakyness under win32.
I assume this thread will attract the usual C++ trolls. "Java's not a real language, blah, blah, blah"
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
I agree with what you say, in that if I launch a calculator program and one takes 100k and the other takes 15MB or RAM then that "can" be an issue. However the difference in bigger applications is not that huge. The amount of RAM needed by the JVM is somewhat static, so the larger the program the less of the difference between it and native code.
I think what you are really saying is that you don't want some piece of crap C program thats big and bloated nor do you want a JAVA program that is big and bloated. In that we agree. The difference in RAM requirements between a DVD burner or MP3 player written in any language shouldn't be that large, and won't be if written by good developers of JAVA or C or C++. The difference is that the one written in JAVA will be easily portable between different systems. The one in C or C++ will probably only be made available on Microsoft Windows.
The more I learn about science, the more my faith in God increases.
WebLogic provides several platform-specific libraries with native language calls for performance (one example is socket and file access). In addition, our particular application uses several platform specific third party libraries, both pure Java and native code. For a while I had to hunt Linux versions of these libraries, but nowadays our vendor partners are pretty good about already having Linux libs.
In a real emergency, we would have all fled in terror, and you would not have been notified.
You're missing the point. If you write once, compile everywhere then you've got another pile of issues to deal with: Is the bug in the compiler? an #include? byte ordering? some library?
There are a huge bevy of tools for dealing with this for C. Other compiled languages have similar problems. With Java all of that goes away: you know whatever problem crops up, it's definitely not the build, because you did that once, at your location, and gave everybody the same binary.
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!)
How do you know and why do you care? If the application would do what you want and meets your needs then who cares what it was written in?
:-)
:-)
Unless you just hate JAVA for some reason and will never run any program written in it. I know some Microsoft people just like you then. They will NEVER run anything that is not developed by Microsoft unless they absolutely have to, and then they just count the days until Redmond releases a "similar" version.
There are some cool JAVA programs out there, that are nice to use because when you want to switch off of an underpowered overpriced laptop to say a "better" platform then you can still run all the exact same code
NOTE: I am writing this on an Alienware laptop
The more I learn about science, the more my faith in God increases.
He is probably like me and hates bloat (other people call it 'eye candy') or just does not use an external mouse and prefers keyboard input. GUIs tend to lose much of their efficiency without a fast, precise mouse (I could argue that there isn't much efficiency to begin with but that is besides the point here).
Linux is not Windows
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?
I agree 100%. I can't stand whiners who claim that Java portability is a myth. The exceptions are trivial and few. It is my opinion that such complainers are either not Java programmers, or whose only interest in Java is finding such examples to trash on it.
I've never seen any issues with GUI code, unless you mean that it doesn't have a native look-and-feel (but then, neither do a lot of recent Windows programs, Microsoft ones included).
The only platform issues I've seen are former VB programmers hard-coding paths with backslashes in them, and OS/390 defaulting to EBDIC encoding for reading files (which had been deployed with the application and were actually in ASCII).
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.
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..
Although you can decompile java byte code with some degree of success, obfuscators exist which can be applied to the byte-code before you distribute it to make decompiling nothing but a waste of time as the code is irrevocably incomprehensible (and some byte-code obfuscators mess things up so bad that the decompiled code won't even compile at all!) Use of such obfuscators is not bad programming practice in the same way that obfuscating source code is because you are still working from clean source. In this sense, java byte-code obfuscators have more in common with the unix utility 'strip', than the conventional notion of an obfuscator. You can set things up in your build.xml or makefile so that the obfuscator can automatically be run on each class file as it's generated, whenever you specify a target intended for distribution.
File under 'M' for 'Manic ranting'
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.
IBM has to provide a JDK for Linux on Power now that they are selling Power servers with Linux. How else can they sell Websphere for it.
Sure, you have to test on all the platforms that you support. But, what language/runtime requires less x-platform testing than Java? Today, the real issue is testing on each J2EE app server. That's where the real issues are. I haven't seen a pure Java platform issue in years.
Apple WebObjects. Powers the iTunes Music Store and Apple Store. Is highly scalable, has great O/R persistence technology and yes, is pure Java.
Funtage Factor: Purple
That is exactly where they initially promoted it, but AWT performance was terrible and few had the broadband to download the jars in a reasonable time.
Bingo! How old is this guy? From Java's launch in the mid-90s, the selling point was as a client-side Internet language that you could use through your browser.
*That* was the hype; applets, applets, applets!
I guess we could blame Microsoft for attempting to foul things up, but the truth is that for 99% of the things Java was initially promoted for, JavaScript was faster (loading) and hence better.
As for AWT performance; Swing on top of *that* was painful on my 233MHz PC. Reminded me of my 68000-based Amiga 500.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Any program you write completely from scratch with C++ could be compiled for any platform. But if you use a third party API in C++ chances are it is not available to you in source, so you are stuck.
Close, but no cigar. If there are enough binaries for the different platforms, you might not need the code. The bigger problem is that people tend to stack libraries - e.g. on the Windows libraries. That will really get you stuck.
The thing about java is that everyone is forced to distribute "source", or more specifically, bytecode, which amounts to the same thing for cross-system compatibility purposes.
Byte-code is far from source. Though many names (public class names, method & field names) are preserved, none of the code within methods, as well as parameter names will be preserved. Please stick to the Virtual Machine paradigm instead - it pretty much explains itself.
Can you make non-portable "libraries" in Java? Yes.
Well, only if you move outside the Virtual Machine (JNI/exec() calls from the VM), since the default API is available on any supported platform. So that's pretty difficult indeed.
We are probably in the same mind on this issue, but it seems that your explanation is more confusing than it needs to be.
Sorry but that is just not true. Example:
With one 1.4.2 point release (not even a minor version), all our applets suddenly became unable to load images. It looked like they changed the rules - previously you could access files beneath the codebase when running locally (ie. without web server), now it gave security violation.
In fact, it turned out that they didn't change the applet security rules, they just required code to be wrapped in a privileged block where it didn't need to be before. The new code won't work on old (eg. MS) VMs either, so now you need JVM version detection etc.
The code was standard image loading stuff (originally used Sun examples IIRC), worked fine from 1.1 through to 1.4.2, then broke completely from 1.4.2_04 (I think) onwards.
Java app can have a perfect "native" look too.
For example, this is the product (sharing and sync application) my friend and I developed:
Windows screenshot
Linux screenshot
or, if you have Java, just Web Start it here - another great Java feature.
What I mean by, "I haven't seen a pure Java platform issue in years" was that I haven't seen a cross platform issue with the Java language or runtime in years. I've seen plenty of pure Java platform (J2EE servers) which had problems running supposedly portable J2EE applications.
both ways are ugly
><////>
oh well, I don't do applets or GUI stuff, maybe I should have included that as a disclaimer in my post ;)
Advanced users are users too!
The formatter is *very* customizable. If the indentation is messed up from you viewpoint, odds are that you typed it in that way.
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
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.
Chapter 1: Confusing the user.
That is the fault of the programmer, not the language.
Chapter 2: Meanlingless error messages
The application programmer decides the error messages. Uncaught exceptions might show to the end user, but if you don't understand these, show me a language with clearer error messages? "ArrayIndexOutOfBoundsException? FileNotFoundException? MidiUnavailableException? What does this mean, I do not understand any of this. Owie my brain hurts...."
Oh, and it is spelled "meaningless". HTH.
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.
Hmm...seems I just responded to a troll.
Being bitter is drinking poison and hoping someone else will die
Ahh, I see. My apologies.
Being bitter is drinking poison and hoping someone else will die
Servlets usually are little. They are only an adapter between HTTP and your application logic. So they are hardly ever longer than a few screens.
Please do not use forward or backward slashes; use java.io.File.separator in string concatenations or use new java.io.File(File parent, String child).getAbsoluteFile() (or .getAbsolutePath()) for 'path additions'.
Wenn ist das Nunstueck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput.
And for example C++, it should be "write once, port anywhere and then test anywhere"? At least with Java, you can skip one step.
8 of 13 people found this answer helpful. Did you?
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?
1. Almost any program can be slow or fast depending on the coder. I suggest you take a look at some of the more modern Java programs and JVMs.
:-) 15MB is almost considered a joke now, and will be in a few more years.
2. Define insane. OpenOffice takes a ton more memory than say vi. Then again they do different things. Java can take more memory, however as I posted before, if the program is bigger than say a simple calculaor program that difference isn't huge.
3. The look and feel can be set for all the major platforms. You will NOT be able the difference of a JAVA app (by look and feel) when done well for Windows or the Macintosh. Now Linux.... you have to be kidding me right???? I have apps written in plane old X, GNOME, and KDE running on my system. None look or feel the same.
4. The JVM can be larger than 15MB. Yes this ONE TIME DOWNLOAD can be an issue. We agree that this can be an issue. Now I find it interesting that most people like you who bitch about this won't complain one bit about downloading a 600-2000MB file to play say a Doom3 demo. So I again say that if you want a cool office program and it is 600MB, but 50MB of it is a JVM then that isn't that big of a deal.
My last comment on this... As far as speed and size in RAM goes - Your same arguments use to be made by people about C code vs machine code or assembler code. A program that was in assembler would be 50 to 100 bytes in size while a C program would be an enourmous 5k. I remember having a discussion with one of our coders much like you and I are having now 20 years ago. His comment was "This freaking C code is crap! It takes 5k to do what I can do in 54 bites! What a slow bloated piece of crap language it is."
My how times have changed, yet the arguments try and stay the same
The more I learn about science, the more my faith in God increases.
See http://www-106.ibm.com/developerworks/java/jdk/lin ux/tested.html
for a list of supported distros and architectures for the IBM JDKs. You'll see that IBM supports Linux on PPC both 32 and 64 bit.
catch (ModDownException mde) {post.modUp("Interesting")}
Lucky you. jdk1.4 bit our back end app in two ways I remember. First, the "assert" keyword broke our build. No big deal, but a pain. Second and much worse, classes in the default classpath became unusable. This made a third party piece unusable. Granted, the third party's code was in poor taste, but it 1) was just like Sun's examples 2) worked and 3) was (arguably) compliant with the spec.
Sun broke their working code. We lost functionallity because of this.
Nevermind the times the JDBC guys break their interfaces. They have even changed return types! You can't write code that implements the interface in both versions. Thanks guys, you should win an award for most fsck'ed.
Different OSs, no problem. Different versions of the JDK, watch out.
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.
I wonder how Java's apt will mesh with Debian's one.
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.
I was there, thank you very much. But this server-side push with Java is still silly IMHO. More effort should have been put into making it the most viable client-side language, which it never became. Why on earth would anyone run their server-side inside a VM? The server side is the platform you control, the one where you can choose a single platform and don't have to worry so much about portability...
I still blows my mind that Java has come as far as it has to date on the server side, and equally blows my mind that it didn't make better inroads as a platform for thin client GUIs.
11*43+456^2