Slashdot Mirror

They usually do provide both. I work on the J2EE Tutorial, which documents the APIs included in the J2EE platform. There's also the Java Tutorial, which documents the standard JDK/JRE platform APIs. For other APIs, check the BluePrints or other tutorials & code camps. Not to mention the case studies and the code samples bundled with other distributions.

The problem with including tutorial or extensive sample material in API documentation is it's too disparate, and not useful when dealing with more complex applications that use a number of APIs. If you're writing a servlet that uses JDBC to pull data from a database, where does the sample code go?

-ian

They usually do provide both. I work on the J2EE Tutorial, which documents the APIs included in the J2EE platform. There's also the Java Tutorial, which documents the standard JDK/JRE platform APIs. For other APIs, check the BluePrints or other tutorials & code camps. Not to mention the case studies and the code samples bundled with other distributions.

The problem with including tutorial or extensive sample material in API documentation is it's too disparate, and not useful when dealing with more complex applications that use a number of APIs. If you're writing a servlet that uses JDBC to pull data from a database, where does the sample code go?

-ian

They usually do provide both. I work on the J2EE Tutorial, which documents the APIs included in the J2EE platform. There's also the Java Tutorial, which documents the standard JDK/JRE platform APIs. For other APIs, check the BluePrints or other tutorials & code camps. Not to mention the case studies and the code samples bundled with other distributions.

The problem with including tutorial or extensive sample material in API documentation is it's too disparate, and not useful when dealing with more complex applications that use a number of APIs. If you're writing a servlet that uses JDBC to pull data from a database, where does the sample code go?

-ian

if not, take a look at Sun's Sun Ray Server Software (aka SRSS). it runs on linux now, but it costs $

we use it here (version 2 tho) and it works fine. you can be doing your thing, go to lunch, leave your apps running, come back (to another client even), and your apps are right there for you

Guess again.

It's a Sun Java System Web Server.

Here is the server software, and it runs on Linux, but unfortunately they don't make a software client (not too surprised since Sun IS a hardware company, even though they try to be a software company). This is the part of the solution that never made economic sense, since the HW clients are pretty expensive, compared to PC's.

The single most important part of any SDK is a tutorial that is aimed at absolute novices. You must assume that your users will have had absolutely no prior experience with your SDK, with any similar SDK, or perhaps any programming language. The "Your First Cup of Java" tutorial is a pretty good example of what I mean.

Your tutorial should be simple enough that the most stupid person you can ever imagine using your SDK will find it straightforward. Perhaps test it on a non-technical user like your mother or some kind of office clerk.

You should try to minimise the length of time required to complete the tutorial. Less than an hour is good. The tutorial should let the user understand what your SDK does, how to start using it (including installing it), and what sort of things they can do with it.

• If a user cannot install your SDK, they will never use it.
• If a user does not understand what they must do "first", they will not be able to use your SDK.
• If a user cannot see why they would use your SDK (particularly over another, similar product), they will not use your SDK.
• If a user cannot afford the time required to learn your SDK, they will not use it.

SDKs are boring. If you can make the user leave your tutorial with a smile on their face and a good feeling about your SDK, then they will come back for more.

A good tutorial should leave the user feeling confident that they can go out into this new world on their own and survive. This can partially be achieved by concluding with a handful of good links that the user can follow to get more information. For example, give a link to a walkthrough of a simple---but non-trivial---application developed using the SDK. Give a link to the automatically generated API documentation. Give a link to a document that explains the architecture and overall philosophy of the design of the SDK. Give a link to some "do"s and "don't"s. Let the user know where they can turn for help from an actual person.

Sun's guide to writing JavaDoc has lots of good ideas, regardless. As does Sun's guide to API specs.

Sun's guide to writing JavaDoc has lots of good ideas, regardless. As does Sun's guide to API specs.

Back in the late '80s I used Matrix Layout which became http://developers.sun.com/prodtech/javatools/jssta ndard/reference/techart/inteRAD.html . It was a ok, but COBOL and RPG developer, I really never invested the time to learn it properly.

Plus, it is likely a more expensive one for Adaptec (vs. binaries) over the long-haul as they need to make sure that whatever they release for the public's eyes are relatively "clean".

The end result of this could very well be Adaptec throwing something over the fence that is only guaranteed to work with a certain generation of cards with only a certain generation of firmware. Is that really better for their customers than a set of binary drivers?

Heh, additionally...

Or is there some other OpenGL bindings I'm not aware of?

These two aren't bundled with the JDK for obvious reasons but they're actively developed by Sun:

JOGL seems to be the de facto standard.

Or, as previously mentioned, the OpenGL bindings for Java2D in Java 1.5

last I checked, stock Java came with AWT, and that was it

Actually, no. Swing has been bundled with the JDK for as long as I can remember.

Here's a snipplet from the official Javadoc package list:

javax.swing
javax.swing.border
javax.swing.colorchooser
javax.swing.event
javax.swing.filechooser
javax.swing.plaf
javax.swing.plaf.basic
javax.swing.plaf.metal
javax.swing.plaf.multi
javax.swing.plaf.synth
javax.swing.table
javax.swing.text
javax.swing.text.html
javax.swing.text.html.parser
javax.swing.text.rtf
javax.swing.tree
javax.swing.undo

AbstractAction, AbstractButton, AbstractCellEditor, AbstractListModel, AbstractSpinnerModel, ActionMap, BorderFactory, Box, Box.Filler, BoxLayout, ButtonGroup, CellRendererPane, ComponentInputMap, DebugGraphics, DefaultBoundedRangeModel, DefaultButtonModel, DefaultCellEditor, DefaultComboBoxModel, DefaultDesktopManager, DefaultFocusManager, DefaultListCellRenderer, DefaultListCellRenderer.UIResource, DefaultListModel, DefaultListSelectionModel, DefaultSingleSelectionModel, FocusManager, GrayFilter, ImageIcon, InputMap, InputVerifier, InternalFrameFocusTraversalPolicy, JApplet, JButton, JCheckBox, JCheckBoxMenuItem, JColorChooser, JComboBox, JComponent, JDesktopPane, JDialog, JEditorPane, JFileChooser, JFormattedTextField, JFormattedTextField.AbstractFormatter, JFormattedTextField.AbstractFormatterFactory, JFrame, JInternalFrame, JInternalFrame.JDesktopIcon, JLabel, JLayeredPane, JList, JMenu, JMenuBar, JMenuItem, JOptionPane, JPanel, JPasswordField, JPopupMenu, JPopupMenu.Separator, JProgressBar, JRadioButton, JRadioButtonMenuItem, JRootPane, JScrollBar, JScrollPane, JSeparator, JSlider, JSpinner, JSpinner.DateEditor, JSpinner.DefaultEditor, JSpinner.ListEditor, JSpinner.NumberEditor, JSplitPane, JTabbedPane, JTable, JTextArea, JTextField, JTextPane, JToggleButton, JToggleButton.ToggleButtonModel, JToolBar, JToolBar.Separator, JToolTip, JTree, JTree.DynamicUtilTreeNode, JTree.EmptySelectionModel, JViewport, JWindow, KeyStroke, LayoutFocusTraversalPolicy, LookAndFeel, MenuSelectionManager, OverlayLayout, Popup, PopupFactory, ProgressMonitor, ProgressMonitorInputStream, RepaintManager, ScrollPaneLayout, ScrollPaneLayout.UIResource, SizeRequirements, SizeSequence, SortingFocusTraversalPolicy, SpinnerDateModel, SpinnerListModel, SpinnerNumberModel, Spring, SpringLayout, SpringLayout.Constraints, SwingUtilities, Timer, ToolTipManager, TransferHandler, UIDefaults, UIDefaults.LazyInputMap, UIDefaults.ProxyLazyValue, UIManager, UIManager.LookAndFeelInfo, ViewportLayout

Each one of the other javax.swing.* packages in that package list have more or less the same amount of class members as the one pasted above.

STILL do not believe me? Download the JDK and compile the program below:

import javax.swing.*;
class SlashdotProof {
public static void main(String[] args) {
JFrame me = new JFrame();
me.add(new JLabel("Is This Proof Enough?"));
me.pack();
me.setVisible(true);
}
}

As you can see, Swing is definitely present in "stock Java."

Geez, maybe you should pay attention to what you are answering. As I said already, most people do not care about development of software and totally don't care about software development tools.

Those who do, can quite easily work under MS Windows by using Free Software tools. GCC - go down the list and you will see that you can get yourself a build that works on MS Windows.

Here is a PHP installer for Windows.

Here is a JDK installation for windows from Sun.

Here is a bunch of Free apps that will run under Java on any platform Apache

Here is a nice development tool for you - Eclipse.

Here is cygwin, in case you want your vi and other *nix tools under MS Windows.

I can give you thousands more examples. A whole bunch of interpreted languages, native compilers, free dev tools, you name it. It all works under Windows. You are spreading the FUD.

Now, as I said, the argument that GNU/Linux costs less works much better for the PCs sold to lower-class people, if it means they can actually afford the box.

If you are a middle-class individual, who can afford the box even if it is whatever X dollars more expensive, you are much better off with a Windows box. The chances are you will want to run MS Windows software and if you cannot then what good is the box?

Anyone at all can download a Free OS, once you have some OS installed on some box.

Of course all operating systems have their security holes. However, it's stily to say that no matter how poor a OS design may be (Windoz), that it doesn't matter and they are "all the same."

...can zombies be clustered?

Clustered using a Win32 worm? No.

A botnet node, however, could easily be manipulated to handle distributed computing such as Folding@Home, SETI@Home, or, with Java, Remote Method Invocation (RMI).

A 50k node botnet with each zombie contributing to, say, cracking an encryption could be invaluable to hackers and a multi-billion corporation's worst nightmare.

The URL in parent should have been:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4799499

This may have a reason. Swing doesn't work properly on Linux. At least not if you don't use an US keyboard and US locale. In many European locales some characters will be untypable, what exact charaters depends on the locale.

This is of course a bug, but its been around ever since swing was born. It was almost emediatly bug reported. After a couple of years sun closed the bug with the bug still UNFIXED. I guess it got embarassingly high bug votes on their top 25 list.

Now the bug is reported again (under a new bug id) and has been on the top 25 list for a couple of years now.

Any Linux programmer know by now, that Sun either is too incompetent or fix this, or have some other agenda that make them unwilling to fullfil the promis of compile once run everywhere that once was used to promote java.

You can get more information on this bug from:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4799499

If you like you can even cast your vote for it to be fixed. Not that I think it will make much of a difference. To Sun java is something for the serverside only.

Yeah, Windows is all alone too.

It's a user guide, not a guide to what's under the hood.

No, the JVM spec and Java language spec are freely available online in HTML and pdf format, or to buy in book form.

There are restrictions placed on people wishing to implement their own JVM/JDK and refer to it as "Java", "a JVM", etc. That's to prevent people from trying to do exactly what MS did and embrace and extend Java by adding classes into the java.* and javax.* package hierarchies.

It's a user guide, not a guide to what's under the hood.

No, the JVM spec and Java language spec are freely available online in HTML and pdf format, or to buy in book form.

There are restrictions placed on people wishing to implement their own JVM/JDK and refer to it as "Java", "a JVM", etc. That's to prevent people from trying to do exactly what MS did and embrace and extend Java by adding classes into the java.* and javax.* package hierarchies.

And a select(2) call and asynchronous IO implementation

I think there's some serious /. style confusion here. Sun does provide the source code for Java: J2SE Source

The restriction is placed on re-distributing modified versions.

does it support the opengl shading language like vertex and pixel shaders

Yes, the latest Java OpenGL libraries do.

i see it supports extensions for opengl 1.5 but to what extent?

Complete support. Including the extensions for NVidia, ATI, GLX, Windows, and Macs.

what about CG for Nvidia or Render Monkey code for ATI?

Yes on CG and OpenGL Shading Language, no on the RenderMonkey. At least, that is, I haven't heard that anyone has added support for it. Does anyone actually USE RenderMonkey? NVidia's having a hard enough time promoting CG with the OpenGL Shading Language out, without ATI pushing its cheap knockoff.

You can always ask the JOGL and LWJGL projects for RenderMonkey support if you simply can't live without it.

what about pointers that you need for A* pathfinding and artificial intelligence?

This makes no sense. AI and A* have both been successfully implemented in Java. I just wrote an A* implementation a month or two ago. Not sure what that has to do with OpenGL.

you cant be serious in considering that Java is a reputable alternative to writing robust recent good quality 3D openGL apps can you?

It's still a pretty immature market, but Wurm Online, Chrome, Xpand Rally, MegaCorps Online, Hockey Challenge and others would take issue with your statement.

But don't take my word for it. See for yourself.

Then, they should work to standardize on http://www.autopackage.org/ [autopackage.org], or something very similar to it.

JPackage perhaps? :-)

There is also a popular request for enhancement hereurging sun to make the Java RPM play better in Linux, i.e. respecting the filesystem standards for where to place documentation etc.

I doubt that GCJ is going to take over on Linux though. Not that they aren't doing FANTASTIC work, but there is still lots of catching up to do and Java is a moving target.

Anyone who reads Jonathan Schwartz's blog will know that Sun is gonna open-source java. He's been hinting about it for a while now, interspersed with hyping up the open-source release of solaris. Sun seems to understand that going open-source is there best chance of survival in the software world.

But what the heck did Larry Ellison smoke this morning? Larry, go read your own web page, look which platform makes the fastest growth for you at the moment, and think it over again.

Or EMC - why did you buy VMware to begin with, if you think that the ESX server base OS does not scale, and is insecure? Oh you added your own patches? Okay - where is the source code, and how about forks?

Hey Cisco, do you have a problem with Asterisk in the upcoming VoIP hype?

And Sun... well they advertise SUSE Linux and Red Hat Linux on their web page, but I didn't expect these free riders to actually *support* Linux. These folks turn any discussion from Linux as a teaser to Slowaris x86 within a wink of the eye. The fork discussion is particularly interesting. As far as I remember, it was not Sun Microsystems who prevented the UNIX fork from happening in the 80s and 90s, despite all the XPG4's, SPEC1170's, Single UNIX Specifications and all these other marketing smoke grenades. "McNealy ... finally announced he won the battle and had the one surviving Unix out there." Scott, go sleep again. Or get sued by SCO because they allegedly own Unix.

Scalability problems is a nice thing. Go read the top500.org list, see what OSses are at the top, and come back then. Hint: it's not Microsoft Windows, and it's not Solaris, especially not the system on rank 2 (has anybody ever seen a 10000+ CPU cluster even *boot* Sloaris or Windows?). The top 10 were not built by EDS, EMC or anybody else on this list. There is *one* Windows system on the list - the entry is 15 months old and fell from rank 84 to 194 within one year. Apparently, nobody dared to run another Windows HPC benchmark ever since. The fastest Sun machine is on rank 31, and guess what, it's not an UltraSPARC box, and did it run Solaris? So far for scalability. BTW: The fastest UltraSPARC machine is on rank 32, and it's not a Sun box, but from Fujitsu-Siemens. Watch your six, there is an Alpha machine behind you!

They assume their customers are deaf, dumb, and blind. Disgusting.

Large enterprises should not use Windows because it is not secure enough, has scalability problems, and is controlled by a single vendor so it's not even *possible* to fork, should you need to.

Note that Dell and Oracle and Sun all have webpages describing their enterprise Linux support. If they were really concerned about Linux not being up to snuff, they probably shouldn't be offering it to their customers.

Good article from all the way back in 2004 regarding where this is actually pointed. http://www.crn.com/showArticle.jhtml?articleID=510 00391&flatPage=true

Would Sun rather see Linux go away? Sure, but they also believe in it enough to sell it. http://www.sun.com/servers/entry/v20z/index.jsp

These are quotes directly from they guy heading up EDS's strategic alliances. Not from members of the strategic alliance - has anyone asked Ellison if he thinks Linux is insecure, prone to unfriendly forking? Guess not. http://www.oracle.com/events/unbreakablelinux/inde x.html. Guess not.

Cisco? Well lets see they have linux running on some of their hardware, and apparently its good enough for their engineers to run http://www.nwfusion.com/news/2005/0216cislinux.htm l

So lets round out the list...

EMC - http://www.emc.com/products/systems/linux/index.js p
Dell - http://linux.dell.com/
Microsoft - http://www.mslinux.org/ Err, umm - ok maybe not.

www.sunsource.net
www.opensolaris.org
www.openoffice.org
Sun supports Linux, too

What were you saying?

"Large enterprises should not use Linux because it is not secure enough, has scalability problems and could fork into many different flavours, according to the Agility Alliance, which includes IT heavyweights EDS, Oracle, Cisco, Microsoft, Sun, Dell and EMC."

to:

EDS: Linux is Insecure, Unscalable?

Why not: "Sun: Linux is Insecure, Unscalable (except the ones we support)" or "Dell: Linux is Insecure, Unscalable (except the ones we sell)"

Mod article -1, Troll

latest is Java 1.5 aka 'Java 5' (a la Solaris naming convention 8-| ) http://java.sun.com/
is the home of the beast

It's pretty cool. You write a loop like this:

#pragma omp parallel for private(sum) reduction(+: sum)
for(ii = 0; ii < n; ii++){
sum = sum + some_complex_long_fuction(a[ii]);
}

...there goes my handy Sparc server...

Maybe you should run the OS your sparc was made for? Or if it really is that old ther's always NetBSD.

Sun Microsystems, in contrast, considers its UltraSPARC IV to be a multi-threaded rather than multi-processor chip. Intel agrees with Sun. This is not an idle debate, because software is often more expensive when licensed for more processors.

Sun refers to the architecture as Chip-level Multi-Threading (CMT) and according to the white paper, while there are indeed multiple cores, each can also multi-thread:

Sun's CMT processors will also have multiple cores on a single piece of silicon, with each core being able to process multiple threads, as shown in Figure 1.5. As a result, a single CMT processor will be able to process tens of threads simultaneously, exponentially increasing the amount of data processed each second.

Cache also seems to have been considered:

Shared chip resources such as large amounts of cache are designed to speed communications between cores to streamline parallel processing of threads.

So while breathless enthusiasm may not be in order, a certain level of optimism seems warranted :-)

Using of Java this way allows the use of "chubby" clients. The Web browser connects to the server, d/l the Java code, then the application runs as if it were started outside the browser. You can get fancy by having the initial code check for version, d/l the applicaiton then launch it. The application gets access to resources for saving temp files, printing, etc.

Sun has replaced this model with their Web Start technology.

But, Sun in the commondity market?

Sun Grid

Just as managing memory is a "hard problem", but malloc() and free() make it safer, there are toolss that let you use threads safely and easily too.

Consider using something like OpenMP There is nothing dangerous or risky or hard to debug in examples like

#pragma omp parallel for private(sum) reduction(+: sum)
for(ii = 0; ii < n; ii++){
sum = sum + some_complex_long_fuction(a[ii]);
}

http://www.novell.com/products/openenterpriseserve r/beta.html
Open Enterprise Server is now shipping. An evaluation version will be available from the product web site on March 15, 2005. You may choose to download the public beta at this time or return when the evaluation is available.

The Java Enterprise system is available for download in its entirety as a CD Image (ISO) or Compressed Archive

FIrst of all, Candian universities run Solaris exclusively, thus no Exchange server to crack ;)

Secondly, my university's mail server is configured to reject the first attempt to deliver. Since most spam is mass mailed, 95% of the automated tools will not bother with retransmission, while Outlook, Mail.app, etc will re-send, which will be accepted on the second try.

I didn't see a picture of a kernel. It looks like Gnome...

Seriously, though, Java Desktop is just Sun's version of Gnome. They must of done something serious with it to justify charging $50 for it. Not clear what though.

Oh yeah, and it is available for linux.

By the way: Athlon-64 has 16 64-bit GPRs, not 4.

There are a lot of alternatives out there, and your inability to find/use them is not a problem which AMD and Intel are overly concerned with. For instance, here are a few of your options:

64-bit RISC:
http://www-1.ibm.com/servers/eserver/pseries/
http://www-1.ibm.com/servers/eserver/iseries/
http://www.pegasosppc.com/tech_specs.php
http://www.apple.com/powermac/
http://www.sun.com/servers/index.html
http://www.hp.com/products1/servers/HP9000_family_ overview.html
http://h18002.www1.hp.com/alphaserver/index.html

64-bit CISC:
http://www-1.ibm.com/servers/eserver/zseries/
http://www.hp.com/products1/servers/integrity/inde x.html

Now why would Intel/AMD want to make it any easier than it already is for you to switch?

Phil

The reason the dotcom era crashed was because the damn xenophobes running the country didn't let visionaries like Sun's Scott McNealy hire more really bright Israelis and Indians.

Linux-VServer uses a soft partitioning technique based on Security Contexts. It is more akin to Solaris Containers and commercial packages like SWsoft than VMware or Xen. It allows you to create many independent Virtual Private Servers (VPS) simultaneously on a single physical server. However, there is only instance of the operating system running on the server. Each VPS has the illusion that it is running a separate OS, including separate instances of ssh, mail, Web and databases, user account database, root password etc. But there is only one actual operating system, so every VPS is running the exact same OS distribution, release level, patch set etc.

You're right. Microsoft has never been named in a lawsuit and is clearly the safer choice in that respect.

dear reader the gnome armageddon has started,

first of all i want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it. belive me it took me a couple of days writing this text in a foreign language. even if you don't care at all for gnome, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

on the following lines i'm trying to give you a little insight of the gnome [gnome.org] community. the things that are going on in the back, the information that could be worth talking and thinking about.

many of us like the gnome desktop and some of us were following it since the beginning. gnome is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of u*nix. only to name some of its advantages.

unfortunately these advantages changed with the recently new released version of gnome. the core development team somehow got the idea of targeting gnome to a complete different direction of users. the so called corporate desktop user. in other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting gnome on their computers.

having this new target in mind, the core development team mostly under contract by companies like redhat [redhat.com], ximian [ximian.com] and sun [sun.com] decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. so far the idea of a clean easy to use desktop is honourable.

some of the new ideas, features and implementations such as gconf [gnome.org], an evil windows registry like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that gnome leads and the attitude of the core development team made a lot of users really unhappy. these are only a couple of examples and the list can easily be expanded but for now this is enough. now let me try to get deeper into these aspects.

you may imagine that users got really frustrated [osnews.com] because their beloved gnome desktop matured into something they didn't want. during the time, the frustration of a not less amount of people increased. more [gnome.org], more [gnome.org] and more [gnome.org] emails arrived on the gnome mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

but the core development team of gnome don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. the reply they give is mostly the same. users should either go and 'file a bug' at bugzilla [gnome.org] or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback [gnome.org] isn't appreciated.

if you gonna think about this

If you have a 3D video card, try activating opengl acceleration in java. From the script launching azureus, add the following command line property:

-Dsun.java2d.opengl=true

This will activate the opengl pipeline for Java2D calls. (Swing uses Java2D for all rendering...)

Yeah, probably not the best example i can come p with... the BSD TCP/IP had the so called "slow start" bug, and some BSD variants even crashed with the "Ping of death" (a.k.a WinNuke).

Still, there's a lot of quality BSD code used outside BSD systems, both in other OSS systems and comercial ones.

http://java.sun.com/j2se/1.5.0/install.html

it looks like there isn't an OSX version available.

Yes, JNI is horrible and awful and evil. CNI, on the other hand, isn't. (Granted, it's only available for GCJ).