Slashdot Mirror

The Java Tutorials

IMHO, the best way to learn java. Comes from an authoritative source, too :o)

I would skip the Ivor Horton book. I bought it when I first started to learn Java and found it woefully slow placed. Over the course of the tomb you develop a fairly basic app along the lines of C++ and not Java (overly simplified OO design etc). The best stuff out there is actually free. Don't buy the official Java language books because they are usually out of date (we have them in the office collecting dust). To learn the basic core language I'd recommend the Java tutorial and for reference the API JavaDocs. Also forget about Swing and Hibernate until you understand the basic language. http://java.sun.com/docs/books/tutorial http://java.sun.com/javase/6/docs/api John

I would skip the Ivor Horton book. I bought it when I first started to learn Java and found it woefully slow placed. Over the course of the tomb you develop a fairly basic app along the lines of C++ and not Java (overly simplified OO design etc). The best stuff out there is actually free. Don't buy the official Java language books because they are usually out of date (we have them in the office collecting dust). To learn the basic core language I'd recommend the Java tutorial and for reference the API JavaDocs. Also forget about Swing and Hibernate until you understand the basic language. http://java.sun.com/docs/books/tutorial http://java.sun.com/javase/6/docs/api John

• The Java Tutorial
• The Java Api

• The Java Tutorial
• The Java Api

http://java.sun.com/docs/books/tutorial/ You really only need the JDK. I'd get "JDK 6 Update 7 with Java EE" at http://java.sun.com/javase/downloads/index.jsp and also the javadoc distribution. Start with that and a good IDE like Netbeans or Eclipse. I'd actually recommend Netbeans although I use Eclipse myself; Netbeans should be easier to get started with and seems to be a little less quirky. Some of Sun's tutorials have code that are already Netbeans projects. Go through basics first like understanding the langauge (e.g. differences/similarities w/ languages you know) before worrying about stuff like Swing (UI), or anything J2EE-related- you'll get there eventually.

http://java.sun.com/docs/books/tutorial/ You really only need the JDK. I'd get "JDK 6 Update 7 with Java EE" at http://java.sun.com/javase/downloads/index.jsp and also the javadoc distribution. Start with that and a good IDE like Netbeans or Eclipse. I'd actually recommend Netbeans although I use Eclipse myself; Netbeans should be easier to get started with and seems to be a little less quirky. Some of Sun's tutorials have code that are already Netbeans projects. Go through basics first like understanding the langauge (e.g. differences/similarities w/ languages you know) before worrying about stuff like Swing (UI), or anything J2EE-related- you'll get there eventually.

http://java.sun.com/docs/books/tutorial/index.html This is official Java tutorial. http://java.sun.com/javase/6/docs/api/ This is official Java API. You can learn everything (or almost everything, but definitelly it will get you to know much more than you know now) about Java from this. That's the only online stuff I've seen (I mean about any language, not only Java) that's free and is as good as a very good book.

http://java.sun.com/docs/books/tutorial/index.html This is official Java tutorial. http://java.sun.com/javase/6/docs/api/ This is official Java API. You can learn everything (or almost everything, but definitelly it will get you to know much more than you know now) about Java from this. That's the only online stuff I've seen (I mean about any language, not only Java) that's free and is as good as a very good book.

As others have no doubt mentioned, Java is a much simpler language than C++, and, if you know C++, learning the basics of Java will not take comparatively much work. I would recommend reading a lightweight book which concisely explains the basics, and then attempting to write some programs in the language. There is no need to get a book designed from programming novices. You might even look at the Java Tutorials online. http://java.sun.com/docs/books/tutorial/ Additionally, using Google to search for 'Java for C++ programmers yields some useful results, such as this one: http://www.javacommerce.com/displaypage.jsp?name=java_for_cplus.sql&id=18260

Once you get the basic Java syntax (which will not take long looking at the langages you already know), read this book: Effective Java , by Joshua Bloch.
There is also a video on YouTube: Effective Java Programming with Joshua Bloch.
And you can read it on Google Books.

I really like O'Reilly's Java in a Nutshell. Between that and Sun's online Java Tutorial and API Reference, you should be able to get a good start with the language itself.

For more "advanced" topics, there are whole books on Swing, Spring, Servlets, JSPs, EJBs, etc... each with their own encyclopedia of information -- you should definitely learn the core language first, and then decide which of these frameworks interest you, and pick one at a time to learn. Most places will hire you if you have solid Java skills, and will expect you to be able to figure out the framework.

There are many books on individual aspects of the Java language, such as Java Concurrency in Practice -- if you really want to be a Java expert. Most of those job listings you see don't require anywhere near that level of expertise, though.

I really like O'Reilly's Java in a Nutshell. Between that and Sun's online Java Tutorial and API Reference, you should be able to get a good start with the language itself.

For more "advanced" topics, there are whole books on Swing, Spring, Servlets, JSPs, EJBs, etc... each with their own encyclopedia of information -- you should definitely learn the core language first, and then decide which of these frameworks interest you, and pick one at a time to learn. Most places will hire you if you have solid Java skills, and will expect you to be able to figure out the framework.

There are many books on individual aspects of the Java language, such as Java Concurrency in Practice -- if you really want to be a Java expert. Most of those job listings you see don't require anywhere near that level of expertise, though.

Java's an entire ecosystem unto itself these days. So there's no simple answer - you have to figure out what kind of apps you want to be involved in building, then that will inform your choice of Java based technologies. For the most part I do enterprise web site development, and that mostly on the server-side, so I'm a Java EE/Hibernate/Spring/Eclipse person. Plenty of professional experienced Java developers will never use any of those technologies!

Once you've figured out what kind of apps you want to be building, I'd suggest visiting the Sun Forums if you have any technical question and then poking around the Java.net site, theserverside.org, JavaRanch and the java usenet newsgroups to get a better feel for what's out there and how it's rated by developers. Feel free to drop me an email if you have any questions that you want to ask offline.

Ignore the naysayers - for the most part they don't know what they're talking about. Sure you should have other languages under your belt, sure there's offshore competition, but still, Java experts are in demand and they will be for a long time yet.

Sun has developed a program to train for java.

read at the sun site

java is relative simple. Those certification programs give you a guideline what is involved in certain roles. But java is MUCH and lots of simple libraries. that is what people underestimate.

I understand you might not need certification, but the knowledge described there gives a good idea what you need/can put on your CV.

I am not entirely sure what notice you may be referring to. I have never heard of any reference Serializable being deprecated. I highly doubt that this was the intent of what you read. To remove Serializable, at least four of the core API's would have to be completely re-written.

Just look at Collections and you'll quickly understand that to remove Serializable you would have to basically re-write Java.

I am guessing that you read one of the notes that are on many of Swings JavaDoc pages. They all basically say this:
"Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder."

(This was taken from the Java SE 6 JFrame page):

http://java.sun.com/javase/6/docs/api/javax/swing/JFrame.html

All this notice is talking about is that you should not save a Swing objects using Serializable methods then load that class after you have changed versions of the JVM I think this is pretty much a no brainier as far as any class goes. This is because there is no guarantee that the classes private variables have not changed between implementations.

If you it wasn't this kind of note, I would love to find out where you read it.

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.

I've seen this warning on a few Swing classes. After re-re-reading it, I have no idea what they're trying to say, but I'm assuming its EE related (although in the SE Javadocs?). IIRC, RMI is Remote Method Invocation or something to the effect (affect? Arg!) of RPC... I haven't the foggiest what that has to do with short term storage.

At any rate, I stand corrected. Sorry for that rant. Given the chance, I'd do it again, but talk about the Thread class! =)

The Serializable interface has been deprecated and will not be forward compatible

What in the world are you talking about? java.io.Serializable, right? I don't see anything in there that says "deprecated".

This would be especially weird because Serializable doesn't do anything. It's just a marker for a class to say "Yes, I am serializable!" Now you may be able to accomplish the same thing with the new attribute tags, but I see nothing that prevents you from using the Serializable interface.

I think you may be confusing Serializable with something else. :-)

In any case, deprecated features in Java usually don't go away. They simply are not recommended for use any longer.

Or, if they don't like OSS, they could at least get lower-cost solutions like Sun's StarOffice (USD35 per person, allowing up to five installs for that person's use at the organization or elsewhere) or IBM's Symphony. Those are some pretty big names.

No P2P, that's resrtricted by the providers that Apple restricted itself to. You can't even use your iPhone as a modem to your laptop.

The Internet is a packet-switching network. As far as I can tell the iPhone has just as much connectivity as any home computer, it's not sandboxed into some crappy WAP corner nobody cares about.

No there are serious restrictions on how you can use your iPhone. No P2P is one such restriction. The other is you cannot use your iPhone as a modem to link to your computer. That is what decided me against it.

if M (the amount of memory required) consists of m1 + m2 + m3, where:
        m1 is the amount of memory required by the compiled code
        m2 is the amount of memory required by the compiler/interpreter/optimizer
        m3 is the amount of memory required by the problem data

Then it is pretty easy to see that m2 is zero at runtime for compiled code, and that the difference (if any) in m1 for the (supposedly) superior real-time optimization will be far, FAR less than m2 (which will be zero at runtime for compiled code).

m2 should also include shared library memory, single instance or no. So what if most of m2 for an interpreted app is single instance?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4416624
"Class data sharing (CDS) has been introduced in the 1.5 release as the
first step toward addressing this problem. The CDS code was originally
developed by Apple Computer, Inc. during their port of the Java
HotSpot VM to Mac OS X and was further developed within Sun primarily
by xxxxx@xxxxx .
...
The footprint cost of new JVM instances has been reduced in two ways.
First, a portion of the shared archive, currently between five and six
megabytes, is mapped read-only and therefore shared among multiple JVM
processes. Previously this data was replicated in each JVM instance.
Second, less data is loaded out of the shared archive because the
metadata for unused methods remains completely untouched as opposed to
being created and processed during class loading. These savings allow
more applications to be run concurrently on the same machine."

The major reasons for using interpretive languages have always been the improvements in the development cycle. Raw execution performance of interpretive code (JIT or otherwise) is unlikely to ever exceed that of compiled code, for C or any other language, for exactly the reasons outlined above.

The major reasons for using interpreted/compiled/assembled languages have always been the improvements in the development cycle. Raw execution performance of interpreted/compiled/assembled code (optimized or otherwise) is unlikely to ever exceed that of machine code, for exactly the reasons outlined above.

There's only ONE way you're going to get a processor to execute exactly what you specify, not one instruction more, and do so using the minimum amount of memory necessary to perform the task. This isn't very important on today's processors (or those of the last decade).

Or the GUI equivalent. This has long been part of the pitch for desktop virtualisation, whatever the technology used: all the data stays in the datacentre. If we really need an Excel jockey to play with government data, they should be doing so using VDI or some equivalent technology.

Why do you take for granted that f2f meetings are so easy to arrange?
In a small organization, yes, it's easy to have f2f meetings when everybody's in the same room.

I work for a big corporation. I never have trouble arranging face-to-face meetings with people who work on my campus. Possibly upper management is harder to get time with (not an issue in my job), but I suspect I could if I had to. It's not like I don't know where they sit.

At one point in my telecommute experience, my home office was much more functional, much more conveniently located to all my colleagues, and just plain a better choice for meetings :)

In other words, you weren't really telecommuting, you were loaning your home to your company as a remote office and meeting center. Not a typical situation. Most home offices are not conveniently located. That's why most people want to telecommute in the first place: to avoid the hassle and expense of traveling from a relatively inconvenient location.

let a web page have a Java component (for example) that doesn't run in a little box... but instead runs in the background and updates the page

I've never tried it, but there's "com.sun.java.browser.dom", which is supposed to let your applet access the browser's Document Object Model. In keeping with the applet security model, there are limits on what can be done to the DOM; I think access is read-only, although the documentation isn't clear.

In typical Sun fashion, rather than having a basic API that works, this is tied in with "Project Metro" and "GlassFish", and is supposed to work with a Java applications server, so Sun can make some money on the server side. Try these JMaki examples, which correspond to simple AJAX applications but are implemented in Java.

Java itself would be a good alternative to JavaScript. At least it scales up better. But Sun insists on burying the language under a mountain of mediocre and ever-changing libraries.

A question though -- with overcommit disabled, things like java or wine (which allocate several hundred megs of ram to play with whether they actually use it or not) tend to start failing; how does solaris deal with this? I wonder if it's even noticed, as the last solaris box I saw had 8GB RAM and 32GB swap, whereas this problem is more apparent on my 64MB linux VMs...

For every allocation (malloc/sbrk) Solaris reserves that much VM/swap space first before it will succeed the allocation. There is no notion of overcommiting memory (except for MAP_RESERVE).

Java - it needs a Gig of "Code Cache" and with overcommit turned off if not enough RAM+SWAP is available and it fails the allocation. So you are right - increasing swap space and tuning overcommit_ratio should deal with that.

See http://developers.sun.com/solaris/articles/subprocess/subprocess.html for interesting discussion around this topic.

I have had driver problems with Linux as well. Does it have such a site?

PS. You can also check the forums at http://opensolaris.org/os/

"ZFS - Are you really using your server for data storage? SAN or NAS should be a better option depending on your price point"

Why not set up a server for data storage? Then you get all the ZFS checksum/auto-heal/snapshot goodness ?

That's why there is Thumper (aka Sun Fire X4500) that can hold 48TB in 4RU.
Considering that, it makes a 20TB SAN seem small.

The review didn't address desktop vs. server and as a "lightweight" review doesn't look any deeper than the distro package for answers to the questions and objections raised.
OpenSolaris works well as a server OS - that /is/ it's heritage. It's easier to run OpenSolaris headless and on a serial console than any of the *BSD and Linux distros that I've used over the years. All of the "standard" server packages are available to run web and net services out of the box. For truly lights-out server rooms it's still necessary to choose hardware that implements some sort of remote power cycle or remote system monitor capability.
The ZFS filesystem is interesting for desktop installations - it does allow seamless use of the 1-2 terabyte desktop disk configurations that are now possible. ZFS was designed for the datacenter - eliminating the need for the time-honored but fragile combination of journaling filesystem over software volume manager (usually over HW RAID). It's the first real innovation in filesystem architecture since journaling filesystems were developed.
Additional software packages are available from 3 well-known (in the Solaris community, at least) sites. Sun has it's own freeware site, blastwave.org and sunfreeware.com
http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml
http://www.blastwave.org/
http://sunfreeware.com/

The package manager for blastwave.org is their own, the others use the standard Solaris pkgadd commands. The package naming convention is a long-standing convention - each vendor uses a different prefix, making it easy to differentiate the source of packages.
OpenSolaris commands, where Sun hasn't replaced stock UNIX commands with their own, reflect SVR5 standard rather than the more Linux-ish BSD syntax.
One of the places where Sun has replaced "normal" functionality is the init process. SMF is Sun's attempt at fixing the long-standing problems and in-efficiencies of the BSD or SVR5 init process. Apple has launchd, there's openrc and gentoo's baselayout that all have similar goals. SMF works well and there's a fair amount of support on the net for integrating non-distro apps.
One of the "why OpenSolaris" answers is that there is value in running the same OS on the desktop as on the server. For Solaris shops OpenSolaris on the x86* servers provides a common platform that enables system management efficiencies to be extended.

Actually, Solaris doesn't use the BSD TCP stack. They completey replaced the stack in Solaris 10.

It depends: if it's the ZFS specification that's CDDL licensed you're screwed as kernel space goes. However, if it's only Sun's software that writes a ZFS file system (the ZFS drivers and toolchain) it's possible that an alternative implementation of ZFS could be created. Sun have said they're 'investigating' a Linux port.

I've used Solaris (I ordered the DVD over the Internet) and I like it: it's no slower than, say, Kubuntu (KDE4), in VirtualBox, and I love ZFS. Unfortunately, I've misplaced the DVD, and additionally my only DVD burner happens to be playing up, so I'm stuck with the VirtualBox image until I get round to opening up the DVD drive and cleaning it.

I've had several backup/maintenance schemes set up at home over the years, often spanning Windows and Mac machines. Being a Java guy, I found Apache Ant to be a really good tool in place of shell or batch scripts. It's cross-platform, and it's quite extensible. And of course Java has pretty comprehensive cryptography API. And it wouldn't be much to wrap it all in a decent GUI, if that strikes your fancy or you want to roll it out to someone else to use, who's not comfortable with the lower level stuff.

I suggest checking out the Java proxy class.

What a load of crap. There are many multilevel systems that hook to multiple classification networks at the same time. One box, connected to both SIPR, and NIPR, for example.

Here's one of them, Radiant Mercury: http://www.globalsecurity.org/intell/systems/radiant_mercury.htm

Here's another. DTW, the DoDIIS Trusted Workstation. It has the capabilty to hook up to many networks at the same time, from NIPR to SCI: http://www.sun.com/solutions/documents/business-cases/go_DTW_cc.pdf

But, hey. Truth doesn't sell magazines, does it? Ironically, the technology that allows more than one classified network to hook to another is pretty freaking awesome. PopMech should take a look at that, instead.

Actually no, if the language you're using (e.g. Java) restricts break and continues to refer only to loops that they appear in the body of

I take it you don't know about loop labels in Java?

I'd forgotten (or perhaps my subconscious shielded me from the memory) that Java even had a goto mechanism.

goto is a reserved keyword in Java, but it is not used in the language. In fact, one of the reasons for it to be reserved is to tell programmers who use goto to stop doing it!

Lets see, Sun's list includes Linux, Solaris and Windows as official downloads. Mono has Linux (albeit distro-specific versions on the site), Solaris, Windows and Mac OS X. Mono also has an unofficial *BSD port, while Java has unofficial ports for Mac OS X (or at least "not listed by Sun but listed by Mac, and a bit behind") and BSD. I'd say that's pretty even.

As for build-once, run-anywhere, yes it is but you end up with either an ugly old and clunky GUI (AWT/Swing) or you end up with OS dependencies (SWT). System.Windows.Forms isn't fantastic on other OSes, but at least it doesn't stand out in a terrible way, just in a neutral way.

The blocks of a ZFS storage pool form a Merkle tree in which each block validates all of its children. Merkle trees have been proven to provide cryptographically-strong authentication for any component of the tree, and for the tree as a whole. ZFS employs 256-bit checksums for every block, and offers checksum functions ranging from the simple-and-fast fletcher2 (the default) to the slower-but-secure SHA-256. When using a cryptographic hash like SHA-256, the uberblock checksum provides a constantly up-to-date digital signature for the entire storage pool. Which comes in handy if you ask UPS to move it.

http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data

The ps3 has 8 cores. It's cheap. Something, e.g., with Sun's UtraSparc T2 costs over US$ 14,000.

http://www.sun.com/servers/coolthreads/t5140/

The ps3 is multicore for the masses. They're here.

This is, like, having an Apple ][ in 1977 :-).

I agree with the parent, the article is a bit unclear. If I read this correctly:
http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/java_js.html
Unsigned java applets are usually highly sandboxed (they can't even access the DOM) and can only communicate with the server they reside on (e.g facebook webserver). So, wouldn't one need another exploit to get around the VM sandbox before even considering using this?

That's flamebait but nonetheless...

It's not as if Java never had any buffer overflows.

As for C/C++, with great power comes great responsibility, either that or for the love of Pete use an std::vector.

http://www.sun.com/servers/x64/x4540/ 48 TB for roughly 22 000$.

...by design. TFA doesn't delve into too much detail, but a sudden power loss on such software RAID systems is a condition that ZFS accounts for. Its Copy-on-write (COW) and write-length stiping strategy prevents things such as the RAID5 write hole condition, a condition that has the biggest chance of occurring when a power loss event happens.

Whilst you obviously know plenty about C++, you seem to know precious little about Java. For one thing, creating an object in Java is faster than in C++ because it doesn't have to malloc at all. Then there's the rather obvious counter to your example which is that it only works if I know I need a million objects ahead of time, and I know exactly which class they all need to be. What if I'm building them based on events? What if some are different types? That's a more common use case and one which your solution simply doesn't work for (unless you start allocating vast buffers just in case you need it, which is more than a little wasteful!).

A little light reading.

I have heard this claim, oh so, many times and have never seen it come to fruition except for exceptionally trivial examples
That's probably because few people take the time to write non-trivial apps in both C++ and Java to compare them. That, and benchmarks are useless. So we can't directly compare results, we have to reason about what's going on under the hood by comparing machine code. Fortunatly that isn't just possible, it's been done, and there are plenty of examples out there. But just think about it in the abstract - there's no way that a compile time optimizer could be better than a run time one, given that they both have access to the same selection of possible optimizations. The run time one will have _at least_ as good a chance of choosing the right one, and, in most cases, a considerably better chance.

Whilst you obviously know plenty about C++, you seem to know precious little about Java. For one thing, creating an object in Java is faster than in C++ because it doesn't have to malloc at all. Then there's the rather obvious counter to your example which is that it only works if I know I need a million objects ahead of time, and I know exactly which class they all need to be. What if I'm building them based on events? What if some are different types? That's a more common use case and one which your solution simply doesn't work for (unless you start allocating vast buffers just in case you need it, which is more than a little wasteful!).

A little light reading.

I have heard this claim, oh so, many times and have never seen it come to fruition except for exceptionally trivial examples
That's probably because few people take the time to write non-trivial apps in both C++ and Java to compare them. That, and benchmarks are useless. So we can't directly compare results, we have to reason about what's going on under the hood by comparing machine code. Fortunatly that isn't just possible, it's been done, and there are plenty of examples out there. But just think about it in the abstract - there's no way that a compile time optimizer could be better than a run time one, given that they both have access to the same selection of possible optimizations. The run time one will have _at least_ as good a chance of choosing the right one, and, in most cases, a considerably better chance.

A don't think a lot of gamers (or other consumers) will want this. A more typical application would be visualization. SGI still does business in this area. Eventually, commodity computers will drive them out of this business, just as they did the workstation business. And fancy graphics cards that fit in standard PCIe slots is part of the reason.

I suffer from memory shock on a daily basis. I work in the x64 part of Sun, and I got into a friendly argument with a SPARC guy about whether our half-terabyte server is better than their.

On the downside: just upgraded my tablet to 4GB, only to discover that Win32 can only handle 3 of them.

A don't think a lot of gamers (or other consumers) will want this. A more typical application would be visualization. SGI still does business in this area. Eventually, commodity computers will drive them out of this business, just as they did the workstation business. And fancy graphics cards that fit in standard PCIe slots is part of the reason.

I suffer from memory shock on a daily basis. I work in the x64 part of Sun, and I got into a friendly argument with a SPARC guy about whether our half-terabyte server is better than their.

On the downside: just upgraded my tablet to 4GB, only to discover that Win32 can only handle 3 of them.

What about a Sun workstation?

Not to mention whole fucking Solaris are guaranteed to be source compatible and most of the time is binary compatible aswell, isn't it?

http://www.sun.com/software/solaris/guarantee.jsp

Seems like it has binary compatibility since Solaris 2.6 and since Solaris 10 source compatibility across x86 and SPARC as well.

Are IBM, HP, or Sun on the scale you require. Honestly there are many, many options out there when you deal with Linux. It is no longer just an OS for hobbyists.