Slashdot Mirror

$100k may seem like a lot to most of us, but that won't even buy a fully populated V890.

Errr... A lot of Sun customers use Volume Manager (VxVM) on Solaris, in fact you can buy it direct from Sun!

Linux HW reqs
Mac 10.4 HW reqs
Solaris 10 HW reqs
In the linux article, the guy got it (don't now distro or version) running on a 33mhz machine, but with no gui.
The mac requires a g3 or up, and 256 MB ram and 3GB HDD space, 4GB with XCode
Solaris requires 120MHz cpu and 256 MB ram (or 512 for PXE), 2GB HDD space

I use Ubuntu as well as Debian, both on desktops and servers. Here is a couple of advantages Ubuntu has over Debian on servers:

• Server install. I have to point it out because many people don't know it but installing Ubuntu doesn't necessarily mean installing a full-fledged desktop OS. You can actually select the "server" option during installation and it will only install server-related packages with no X11/X.org packages whatsoever.
• Fixed release schedule. Ubuntu releases a new version of its install CDs every 6 months while Debian is more irregular and does it less often. It makes it easier for example when you need to install Ubuntu on recent hardware, the kernel is generally more up-to-date and Debian may not detect all of your hardware. Of course it is always possible to find workarounds for Debian (loading an optional kernel module, netbooting a more recent kernel, etc), but it involves more work.
• Packages freshness. Ubuntu tends to have more recent packages than Debian. For example I recently had to install 2 servers, one Ubuntu and one Debian, that had to boot off a software md RAID setup. It worked off-the-shelf with Ubuntu because it uses a more recent initrd package (mkinitramfs, IIRC) while the latest AMD64 Debian release uses an older initrd package (initrd-tools) that was unable to correctly detect and assemble the RAID arrays when booting up, I had to manually fix that to make it work.
• Homogeneity. When you already run Ubuntu on your desktop machines, running the same OS on your servers (without the desktop packages of course) simplifies everything: your local package mirroring server only has to mirror packages for 1 OS, maintaining and supporting only 1 OS requires less work than 2 OSes, etc.
• Developers. It seems Ubuntu developers are extremely active and, simply said, bright people. I have already fixed a couple of bugs in various Ubuntu scripts/packages over the past year or so and Ubuntu developers have always been very quick to respond and apply the patches. I also tend to keep an eye on what they are doing and it is obvious that Ubuntu developers make a lot of efforts to correctly engineer every little detail in their distribution.

As a Unix guru/developer I also regularly use a couple of other Linux and BSD distros (FreeBSD, Gentoo, OpenBSD, etc) because I like to experiment a lot and like to live on the bleeding edge of technology, but all in all I have realized that Ubuntu plainly rocks and there is a lot of reasons why it is becomming so popular. I think every IT engineer easily understands the advantages of Ubuntu. And somehow it totally makes sense that Sun, "a company built for engineers, by engineers" [1], is interested in Ubuntu :-) I am a technological perfectionist and Mark Shuttleworth (the man behind Ubuntu) seems to have created a distro the way I would have done it. It is well engineered and It Just Works (TM).

It's Niagara T1 CPU [sun.com], not Niagra! Can you tell I'm writing an anti-spam HOWTO based on my FreeBSD setup I use?

And it had to be the first time I got a post approved...ah well.

it's Niagara T1 CPU, not Niagra.

I'm suprised no one, especially Sun, have tried it earlier.

They did (along with lots of other OSS toolkits - get googling)

So how exactly is this in any way easier than simply dragging and dropping your AJAX components onto your project using the Java Studio Creator ?

As you can read here they're offering a large set of AJAX components which can be used. IMO its a much saner approach than to rely on some "code creating" toolkit. I'd rather decently write my components once and then start using them many times, knowing that it doesn't contain any backdoors and simply does what it should and nothing else. Also see this site.

So how exactly is this in any way easier than simply dragging and dropping your AJAX components onto your project using the Java Studio Creator ?

As you can read here they're offering a large set of AJAX components which can be used. IMO its a much saner approach than to rely on some "code creating" toolkit. I'd rather decently write my components once and then start using them many times, knowing that it doesn't contain any backdoors and simply does what it should and nothing else. Also see this site.

So how exactly is this in any way easier than simply dragging and dropping your AJAX components onto your project using the Java Studio Creator ?

As you can read here they're offering a large set of AJAX components which can be used. IMO its a much saner approach than to rely on some "code creating" toolkit. I'd rather decently write my components once and then start using them many times, knowing that it doesn't contain any backdoors and simply does what it should and nothing else. Also see this site.

Sun's press release
Offical Sun JDK Distros Project
Like a lot of people are already saying, you've been able to get the JDK source code for a long time now. The goal here is to fix the things that keep most Linux distro from including a JRE/JDK.

The SCSL does not cover the version of javac included in Java 1.5 or older versions

??? I think you're confused. The JavaC compiler is there under j2se/src/share/classes/sun/tools/javac. Considering that each version of the SCSL code is used to build successive versions under Linux/FreeBSD, I have a hard time believing that the source code isn't included!

Download the source code and see for yourself.

Also, the Generics compiler was released separately when Sun was testing it. The full source code is there if you'd care to play with it.

The SCSL does not cover the version of javac included in Java 1.5 or older versions

??? I think you're confused. The JavaC compiler is there under j2se/src/share/classes/sun/tools/javac. Considering that each version of the SCSL code is used to build successive versions under Linux/FreeBSD, I have a hard time believing that the source code isn't included!

Download the source code and see for yourself.

Also, the Generics compiler was released separately when Sun was testing it. The full source code is there if you'd care to play with it.

JAVA source code has been freely avaible for many years now. If that wasn't that case, you wouldn't be able to for example, build the native FreeBSD JDK...

Finally, Java makes it hard to add debug functionality into your code without a performance hit.

That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.

Actually, you can use the assert facility (since Java 1.4, I believe) to achieve something similar as a pre-processor out of the box.

Specificly, about 60% down the document, the following can be read regarding removing any assertion code from the resulting class files:

Removing all Trace of Assertions from Class Files

Programmers developing applications for resource-constrained devices may wish to strip assertions out of class files entirely. While this makes it impossible to enable assertions in the field, it also reduces class file size, possibly leading to improved class loading performance. In the absence of a high quality JIT, it could lead to decreased footprint and improved runtime performance.

The assertion facility offers no direct support for stripping assertions out of class files. The assert statement may, however, be used in conjunction with the "conditional compilation" idiom described in JLS 14.20, enabling the compiler to eliminate all traces of these asserts from the class files that it generates:

static final boolean asserts = ... ; // false to eliminate asserts

if (asserts) assert <expr> ;

Finally, Java makes it hard to add debug functionality into your code without a performance hit.

That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.

Actually, you can use the assert facility (since Java 1.4, I believe) to achieve something similar as a pre-processor out of the box.

Specificly, about 60% down the document, the following can be read regarding removing any assertion code from the resulting class files:

Removing all Trace of Assertions from Class Files

Programmers developing applications for resource-constrained devices may wish to strip assertions out of class files entirely. While this makes it impossible to enable assertions in the field, it also reduces class file size, possibly leading to improved class loading performance. In the absence of a high quality JIT, it could lead to decreased footprint and improved runtime performance.

The assertion facility offers no direct support for stripping assertions out of class files. The assert statement may, however, be used in conjunction with the "conditional compilation" idiom described in JLS 14.20, enabling the compiler to eliminate all traces of these asserts from the class files that it generates:

static final boolean asserts = ... ; // false to eliminate asserts

if (asserts) assert <expr> ;

Well, for one thing, it is slower than native code

Statement with no proof, got to love that. If you even bother googling "java vs c++", you'll see plenty of benchmarks that demonstrate pretty much speed parity at non-GUI tasks.

For another, its garbage collection has a tendency to result in really bad performance stalls, making it useless for anything involving real-time (eve soft real-time) performance

Hence the reason for the related JSR and Sun's implementation.

For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support, making it not much more OS-independent than C when it comes to open source development. The result is that any apps that are very complex at all will utterly fail to "run anywhere".

Not much to argue although the JDK is constantly expanding to incorporate new features. The trick of course comes in when you have to decide - if feature X is only available on Windows, does one include it? Generally however, this is only an issue for the desktop - a space it's been struggling in. The enterprise market doesn't tend to face this issue.

For another, there is little incentive to ship a single binary for multiple hardware platforms. The extra overhead of building a binary for another platform is negligible once you get past the OS-dependent stuff (which Java for the most part fails to solve). If you have to do extra work for each platform anyway, you're 80% of the way to doing it right....

Umm... the JVM comes for a wide variety of platforms - even the ones for which Sun doesn't release the JVM, the companies developing the OS do (i.e. AIX, MacOS). And you say that Java fails to solve the OS-dependent stuff - compared to C/C++ it's far far ahead. I mean look at something like Netbeans - no OS dependent stuff (except maybe some look and feel). So you're argument is just flawed in so many ways.

Next, Java generally fails to result in apps that match the native OS look and feel, so Java apps tend to seem very foreign on any platform on which you run them.

When was the last time you actuall used Java. Swing's come a long way and integrates very cleanly into the OS (if done correctly). And it's also getting faster with every release.

They don't integrate well with other apps, don't do a good job of supporting OS services, etc

Not quite sure what you mean there.

With C and C++, assuming you separate out the interface properly, it is possible to write an app in which the vast majority of code is shared across platforms, but the UI portions are per-platform.

With Java you don't even have to do that saving on development time. Not to mention that with C/C++ you have to be familiar with the appropriate OS-specific API. With Java, there's only 1.

This allows much tighter platform integration for a relatively small amount of effort. You just can't do that sort of thing with Java in any practical way.

Define "relatively small" and what features you're adding that make integrate it better. And with Java you can do it in a more practical way - that's why there are 3-party libraries such as the Java Desktop Project

Finally, Java makes it hard to add debug functionality into your code without a performance hit. You can do this trivially in C with #ifdef code that makes the debug code fall out entirely. All you can do in Java is run-time testing, which hurts performance. The more debug code,

what the "pundits" have been calling for is the source code to the virtual machine and the compiler

WindBourne! I'm shocked to hear such garbage from you!

Current "Stable" JVM - <= 1.5 (SCSL)

"Unstable" JVM Branch - 1.6 (JRL)

Every, (and I do mean every) story on Java here on Slashdot has contained one of those two links. Most of them contain BOTH. Why? Because the trolls come out in force. The fact that you didn't take the time to look into the matter (I believe I suggested Googling for it) is disappointing and disheartening. :-(

More likely, Sun will make the source CDDL like the rest of their free-software (and hardware :) ) offerings

More likely, Sun will make the source CDDL like the rest of their free-software (and hardware :) ) offerings

Don't get me wrong, I'm all pro-FOSS, still... We have this: http://java.sun.com/j2se/1.5.0/source_license.html and I don't see how this "new" turn of events will further help Java. I think it will be like with OO.org, it's open still, only a handfull of devs care about it for various reasons. I really like Sun as a company and as a source of hw and sw (no, I'm in no way affiliated or related) and I hope this turn will be in the right direction.

As I understand it, as a novice, the only way to communincate or syncronize data is via copies of data passed via something analogous to a socket. A Socket is a serial interface. If you think about this for a moment, you realize this could be thought of as one byte of shared memory. Thus a copy operation is in effect the iteration of this one byte over the data to share. At any one moment you can only syncronize that one byte.

But this suggests it's own solution. Why not share pages of memory in parallel between processes. This is short of full access to all of the state of another process. But it would allow locking and syncronization processes on entire system states and the rapid passing of data without copies.

There is another solution: All data shares the same address space, so it can be accessed by simple pointers; no copying is necessary. To ensure the integrity of the system, all code in the kernel space must be proofed for correctness. To decrease the cost of such proofs, automatic proofers are used. Such systems are already in use: the proofs are done using a type checker on a type system. The type system ensures, that the data is only modified on a certain way, e.g. using certain primitives. When the code is loaded, a type checker verifies, that the code is properly typed, i.e. follows the rules of the type system. Using an appropriate type system, it can be ensured, that correct locking is performed, that onlycertain modules can access specific data, or that each access is monitored by some security system.

Using a type system to ensure the integrity of the data is used in most modern programming languages. E.g. many applets can share the same address space in the same Java VM; but they cannot tinker with each others data -- the type system prevents this. Type checkers in an operating system are already in use. Examples for this are Kernel Mode Linux and Java Operating System.

To use a type system in the kernel context, it is not necessary to use a full blown virtual machine, which interpretes the code and provides garbage collection. But the assembler code must contain type information. This is ensured by modern assembler varaints, e.g. Typed Assemlber Language or the Low Level Virtual Machine.

Using this approach, you can have a better compromise between speed and isolation. Shared memory looks nice on the first glance, but gives an component full access on the shared data. Shared memory does not solve synchronization. Using a proper type system, synchronisation becomes trivial. Just think of the synchronized keyword or the atomic datatypes in Java.

As I understand it, as a novice, the only way to communincate or syncronize data is via copies of data passed via something analogous to a socket. A Socket is a serial interface. If you think about this for a moment, you realize this could be thought of as one byte of shared memory. Thus a copy operation is in effect the iteration of this one byte over the data to share. At any one moment you can only syncronize that one byte.

But this suggests it's own solution. Why not share pages of memory in parallel between processes. This is short of full access to all of the state of another process. But it would allow locking and syncronization processes on entire system states and the rapid passing of data without copies.

There is another solution: All data shares the same address space, so it can be accessed by simple pointers; no copying is necessary. To ensure the integrity of the system, all code in the kernel space must be proofed for correctness. To decrease the cost of such proofs, automatic proofers are used. Such systems are already in use: the proofs are done using a type checker on a type system. The type system ensures, that the data is only modified on a certain way, e.g. using certain primitives. When the code is loaded, a type checker verifies, that the code is properly typed, i.e. follows the rules of the type system. Using an appropriate type system, it can be ensured, that correct locking is performed, that onlycertain modules can access specific data, or that each access is monitored by some security system.

Using a type system to ensure the integrity of the data is used in most modern programming languages. E.g. many applets can share the same address space in the same Java VM; but they cannot tinker with each others data -- the type system prevents this. Type checkers in an operating system are already in use. Examples for this are Kernel Mode Linux and Java Operating System.

To use a type system in the kernel context, it is not necessary to use a full blown virtual machine, which interpretes the code and provides garbage collection. But the assembler code must contain type information. This is ensured by modern assembler varaints, e.g. Typed Assemlber Language or the Low Level Virtual Machine.

Using this approach, you can have a better compromise between speed and isolation. Shared memory looks nice on the first glance, but gives an component full access on the shared data. Shared memory does not solve synchronization. Using a proper type system, synchronisation becomes trivial. Just think of the synchronized keyword or the atomic datatypes in Java.

nfs defaults to udp

On some OSes. On others, it doesn't; see, for example, the Solaris 9 mount_nfs man page:

proto=_netid_
_netid_ is a value of network_id field from entry in the /etc/netconfig file. By default, the transport protocol used for the NFS mount is the first available connection oriented transport supported on both the client and the server. If no connection oriented transport is found, then the first available connectionless transport is used. This default behavior can be overridden with the proto=_netid_ option.

The Solaris 10 man page says much the same thing, but it explicitly indicates that this means "TCP first, then UDP if TCP isn't supported", and also mentions RDMA.

Why add the overhead and problems (see below) of tcp to an nfs mount?

Because the first problem they mention:

The disadvantage of using TCP is that it is not a stateless protocol like UDP. If your server crashes in the middle of a packet transmission, the client will hang and any shares will need to be unmounted and remounted.

is an implementation problem with the version of Linux's NFS client being described, not a problem of TCP. That paragraph can be replaced by "Linux's NFS-over-TCP client implementation, as of the writing of this document, is incomplete". A complete NFS-over-TCP cient implementation will, if the server crashes in the middle of a packet retransmission, attempt to open a new connection and, if that succeeds, will retransmit any requests to which it hadn't gotten any replies. An implementation that does that will not hang (if the server comes back) and will not require any unmounting and remounting of NFS mounts. The Solaris implementation is complete in that regard, as are, I suspect, most if not all of the Solaris-derived ones (such as commercial UN*Xes that have licensed Sun's implementation); I suspect the BSD implementations are complete in that regard as well.

The other problem listed is

The overhead incurred by the TCP protocol will result in somewhat slower performance than UDP under ideal network conditions, but the cost is not severe, and is often not noticable without careful measurement.

but, as they note, "the cost is not severe", and just because you happen to have ideal network conditions at time T, that doesn't necessarily mean you'll have them at time T + delta T.

Of course MS had enumerations built into Java back in 1998. Why did it take Sun 4 years to even start discussing it?

I'm guessing it was because of things like this. Java has done its best to avoid language bloat; the common term for it is "less is more." It's easy to accomplish the equivalent of an enum using a private constructor and public static instances. So a language-supported enum was regarded as unneeded.

I think the big mistake Sun has is that it is confusing what people mean by open source. When someone says open source they mean not only is the code fully open source but you can change it, redistribute it, and even submit patches to Sun. If you look at http://www.sun.com/software/communitysource/j2se/j ava2/download.xml you will see a few files for the Java souce code. One is simple labeled "JSCSL Source" but another is labeled "SCSL Binaries - needed to complete source build" so Java isnt fully open source. The first thing they need to do is make it so I can download just the source, with no binaries, and compile it on any OS/arch mixure I want. The second thing they need to do is change the license just a bit so that I can redistribute the source code on my own. I think most people would be fine with Sun making their own license that says you must say it isnt the offical Sun Java if you choose to redistribute it. I think right now Sun's big problem is that they dont want something stupid that you do effect Java's reputation.

Since the soundbanks page comes up empty for me, I have no idea what their license is

Yeah, they've got a comment in there that looks like this:

<!------------>

It seems to screw with Mozilla. I was hoping it was just me. It works fine in IE, and probably other browsers. Basically that page says,

This page provides different soundbanks which you can download and use with Java Sound. Soundbanks are necessary for correct operation of the internal software synthesizer that ships with Java Sound. By default, the Windows version of the J2RE does not ship with a soundbank, so you need to manually install one to use Java Sound's MIDI engine. Java Sound has a fallback mechanism that uses a hardware MIDI port if no soundbank is available, but it prevents reliable and consistent MIDI playback, so installation of a soundbank is recommended for Java Sound.

It then explains how to properly futz up the lib/audio directory. The page has no license of its own (including in the download), but there is this blurb at the bottom of the page:

A Sun Developer Network Site

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.

So as far as I can tell, they never explicitly grant you permission.

Really, when it comes down to it Sun has a specific purpose with their license. That purpose is to ensure that a given Java installation can be relied upon. If you're just screwing around and learning about the JVM by adding JDK features to a JRE, they're probably not going to bat an eye. If, however, you're distributing a "patch" to the general public that makes java.lang.String run 30% faster, they're going to be a bit miffed if that patch starts fscking up peoples machines. So in the end, use a little common sense and the license won't matter too much. After all, Sun doesn't install Sun Police 2 (version 1.2) on your machine along with Java. ;-)

Since the soundbanks page comes up empty for me, I have no idea what their license is, so it's hard to guess how the soundbanks license interacts with the JRE one. I would assume that they use the "Supplemental Terms" mechanism, though, to grant themselves the right to do it, without granting you the right to do it with arbitrary files.;)

But looking at http://java.sun.com/j2se/1.5.0/jdk-1_5_0-license.t xt

I don't see what in that license would give you the right to copy any jars from JDK into JRE in the first place. The JDK license also only grants rights for internal use & reproduction of "complete and unmodified" software, which does not allow you to do a partial copy of it (only some jars, as you suggest above).

As for -Xbootclasspath, afaict the person violating the license agreement is the user deploying an application A using the feature to override a class, not someone redistributing the application A, or the JRE.

The reasoning is simple: the redistributor does not need to have a JRE license in order to develop and redistribute the application A, as he could be using, say, gcj and compiling to byte code. Therefore he may not be bound by the JRE license, so he would not be in violation of it. The only person who is certainly breaching the JRE license is the user depoying application A, as he's the one who is bound by it through deploying the JRE.

Finally, as far as modifying one's own install goes, as far as I know Sun, they are indeed concerned about people modifying the certified-as-compatibity-test-suite-passing-binary JRE Sun ships, since doing so makes the certification null and void. A modified, uncertified JRE install effectively breaks the promise of true & tested compatibility that a Java(TM) runtime offers to applications running on it, and that's nothing Sun would want to embrace. ;)

Basically, Sun's whole idea of compatiblity revolves around a concept of a pristine golden master binary, that has been certified as passing the test suites under specific circumstances. If users were allowed to modify those certified binaries upon installation, the certification would not be very useful, which is why users have to agree to use their JRE & JDK "complete and unmodified" and are not allowed to shuffle files around from one into the other.

IANAL, YMMV, HTH, etc. ;)

good night,
dalibor topic

FreeBSD licensed java and now no other bsd can do it. (sun's fault)

See, I have to disagree with your interpretation. By adding the JDK capabilities, you're modifying the installation, not the software itself. Especially since the best method for doing so is to put the dt.jar into the extension folder. In addition, if adding components invalidates your license, then downloading and modifying your JRE installation with the soundbanks would also invalidate the license. But it doesn't.

The reason why using the "-Xbootclasspath" option invalidates the license is because you're intentionally modifying the distribution of the JRE. Note that it does NOT say that merely using the flag invalidates your license. Only that redistributions using the flag invalidate your right to use and redistribute the JRE.

Of course, I'm not a lawyer, but it seems fairly clear to me that Sun is worried about redistribution and reverse engineering, not mucking around with your installation. IMHO, a both Sun and judge would agree. (Again, IANAL, so take my interpretation at your own risk.) :-)

Seriously, how fucking lazy to you have to be not to go here and download it your self. "Java sucks because it's not included with my favorite distro". Waaahhh!

And yes, I'm still waiting for a complete/official specification of what Java and the JVM actually is.

See http://java.sun.com/j2se/1.5.0/jre-1_5_0-license.t xt

Note the following section:

"3. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software."

Note that the restrictions are unconditional. They hold both for redistribution case and the internal use case. In particular for the internal use case, we can look at the

"SUPPLEMENTAL LICENSE TERMS"

"A. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software "README" file, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce internally and use internally the Software complete and unmodified for the purpose of designing, developing, and testing your Programs."

I.e. you must not modify Sun's JRE at all, neither for redistribution, nor on your own installation.

On a side note, Sun, considers deploying applications that make use of -Xbootclasspath to be a breach of the JRE license.

See http://java.sun.com/j2se/1.5/docs/tooldocs/solaris /java.html :

"-Xbootclasspath/p:path Specify a colon-separated path of directires, JAR archives, and ZIP archives to prepend in front of the default bootstrap class path. Note: Applications that use this option for the purpose of overriding a class in rt.jar should not be deployed as doing so would contravene the Java 2 Runtime Environment binary code license."

cheers, dalibor topic

See http://java.sun.com/j2se/1.5.0/jre-1_5_0-license.t xt

Note the following section:

"3. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software."

Note that the restrictions are unconditional. They hold both for redistribution case and the internal use case. In particular for the internal use case, we can look at the

"SUPPLEMENTAL LICENSE TERMS"

"A. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software "README" file, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce internally and use internally the Software complete and unmodified for the purpose of designing, developing, and testing your Programs."

I.e. you must not modify Sun's JRE at all, neither for redistribution, nor on your own installation.

On a side note, Sun, considers deploying applications that make use of -Xbootclasspath to be a breach of the JRE license.

See http://java.sun.com/j2se/1.5/docs/tooldocs/solaris /java.html :

"-Xbootclasspath/p:path Specify a colon-separated path of directires, JAR archives, and ZIP archives to prepend in front of the default bootstrap class path. Note: Applications that use this option for the purpose of overriding a class in rt.jar should not be deployed as doing so would contravene the Java 2 Runtime Environment binary code license."

cheers, dalibor topic

Like many things Sun does with Java technology licensing, it sorta sounds good in theory, but it's next to useless in practice.

In practice, it is impossible to know if anyone else but you has accepted the JRL, unless you look over their shoulders and see them clicking on it. So putting your code on a web page without click-through is right out of question. Putting your code on a conference CD: out of the question. As a JRL-bound researcher, you need to actively enforce Sun's licensing regime on your peers, and there is nothing researchers love more than to spend their time on Sun's legalese.

Analogously, while you can in theory publish papers on the code, you may need good lawyers to check your paper submission, since Sun never says just how much quoting in a paper is OK. Your submission, if it describes interna of Sun's implementation, to compare your own better implementation against it, can be particularly interesting for your lawyers, since Sun claims that their source code is a trade secret, for example in the Mustang beta license:

"Licensee agrees
that Licensed Software contains Sun trade secrets."

at http://java.sun.com/javase/6/jdk-6-beta-license.tx t

Oh, it looks like in Sun's tradition of silent license changes they have changed that recently to say:

"3.2 Licensed Software is "Confidential Information".
Licensee may not disclose or use Confidential
Information, except for the purposes specified in this
Agreement. "

which means the same thing.

cheers,
dalibor topic

Anyhow, all you have to do is to set the system propery swing.defaultlaf to the L&F manager that you want to use. If you want to force the Windows L&F for example, use the following:

-Dswing.defaultlaf=com.sun.java.swing.plaf.windows .WindowsLookAndFeel

You can read all the details, along with the class names to use for other look and feels at the Java tutorial page.

You can get the native c code for the vm and such from here: http://java.sun.com/j2se/1.5.0/scsl/README-SCSL.ht ml

That would be here under the SCSL or here under the JRL. Pick your license. For an explanation, go here. :P

That would be here under the SCSL or here under the JRL. Pick your license. For an explanation, go here. :P

That would be here under the SCSL or here under the JRL. Pick your license. For an explanation, go here. :P

http://www.sun.com/software/communitysource/j2se/j ava2/download.xml

Instead of saying anything rude, here is the f*cking link:

http://wwws.sun.com/software/communitysource/j2se/ java2/download.html

That said, the license is somewhat less than free :-)

http://wwws.sun.com/software/communitysource/j2se/ java2/download.html

All clear?

I work for Sun and we use Sunray thin clients for our desktops. I really like it. Low power, no noise, efficient desktops. With Sun Ray Software 4 you can deliver windows, linux or solaris desktops!!

Check out Sunrays: http://www.sun.com/desktop/index.jsp?tab=1
Check out Sun Ray Software 4: http://www.sun.com/software/sunray/index.jsp

I work for Sun and we use Sunray thin clients for our desktops. I really like it. Low power, no noise, efficient desktops. With Sun Ray Software 4 you can deliver windows, linux or solaris desktops!!

Check out Sunrays: http://www.sun.com/desktop/index.jsp?tab=1
Check out Sun Ray Software 4: http://www.sun.com/software/sunray/index.jsp

(We use Windows CE thin clients from HP, and you just setup one thin client exactly how you like then export the settings to a file, using the file you quickly setup all other thin clients).

Ironically, I'm typing this on a Sun Ray "client" (I'll resist the temptation to quibble with that word) that's connected to a Solaris system. I have no idea what OS the Sun Ray runs, but I'll bet it's not Solaris!

I recommend phoning you local Sun office and ask for a demo & quote for SunRays. I used to work for Sun and all the desks had SunRays instead of(/aswell as) workstations, and I really liked them, even being a techie - although I did have a workstation to develop on also. Recently they also support Windows as the Server/Desktop if that's what you really want (personally, due to cost, I'd go for Solaris or Linux with a Windows like window manager - at least *Nix fans can change their own WM then aswell). I haven't tried all the possible thin client options, but SunRays will be damn hard to beat! Read the datasheet here.

On a general note, I'd recommend looking at all the options in detail and compare initial cost, TCO and usabilitiy before deciding.

I recommend phoning you local Sun office and ask for a demo & quote for SunRays. I used to work for Sun and all the desks had SunRays instead of(/aswell as) workstations, and I really liked them, even being a techie - although I did have a workstation to develop on also. Recently they also support Windows as the Server/Desktop if that's what you really want (personally, due to cost, I'd go for Solaris or Linux with a Windows like window manager - at least *Nix fans can change their own WM then aswell). I haven't tried all the possible thin client options, but SunRays will be damn hard to beat! Read the datasheet here.

On a general note, I'd recommend looking at all the options in detail and compare initial cost, TCO and usabilitiy before deciding.

Don't take C's poor support for threading and tools to build/debug threaded code to mean that writing threaded code isn't possible. Other platforms and languages have taken threads to great extremes for many years, and I'm not necessarily referring to anything Unix (or from Sun).

This reminds me of the story (but I don't know how true it is) that in the early days of Fortran, the quicksort algorithm was widely understood but considered to be too complicated to implement. Now 2nd year computer science students implement it as a homework project. Threads could be considered similar. Anyone who has written a servlet is implicitly writing multithreaded code and you can very easily/quickly write reliable and safe threaded code in a number of modern languages without having to get into the details C forces you into. It's the mix of pass-by-reference and pass-by-value with only a bit of syntactical sugar that creates the problems, not the concepts of parallelism.

On the other hand, I agree with you that we'll see increased parallelism driving increases in computing capabilities in the coming years. It was mathematically proven some time ago, but Amdahl's law is now officially giving way to Gustafson's law (more on John Gustafson here). Since software codes are sufficiently complex these days (even the most simple of modern programs can make use of parallelism-- just think of anything that touches a network), it's those platforms that exploit this feature which stand to deliver the best benefits to it's users.

Please enlighten me on why accessibility in XWindows or in the total OSS environment of your choice is any different/better here.