Slashdot Mirror

To address the number of devices they'll need, I'd bet on their making the transition to ipv6, which has been, unfortunately, stymied and postponed for years now.

Just demonstrating the transition in a rather large real-world application would be one of the more useful spinoffs. At the very least, it will help keep ipv6 efforts alive.

I posted this further down, but Apple already provides a single-VM solution that Sun are looking at. It probably won't be in 1.5 though.

No.
Sun are apparently looking at the work that Apple did to provide this functionality with the Apple implementation of 1.4, but it's not likely to be in 1.5 (see this chat transcript for the official line. Maybe 1.6 for non-Apple VMs?

I find those companies on this list of Java Licensees, so I doubt their implementations are independent. Neither is Blackdown, according to their FAQ. I would be a lot less wary of using one of the listed implementations of Java than using Microsoft's .Net, but Sun does still own Java and I'm still not aware of any completely independent implementations that are not way behind the official one.

I sure hope future languages aren't modeled on Java. That will retard language development like too much reliance on C has retarded it over the last couple of decades. But Java isn't even as original as C was. The language design is purely derivative, a cleaned-up, restricted C++ with some features added from other languages, according to Jim.

I'm not saying Java is a bad language, but that it would be a bad one to base others on.

Interface java.util.Iterator

Give me a native optimizing compiler and I just might reconsider.

Agreed. And not only that, but the big computer corporations often started with class A (16 million addresses) blocks, and acquired more over time. HP, for one, has its own class A, Compaq's class A, Digital's class A, and I believe also has Tandem's class A as well. That's 48 million IP addresses. I bet that a full .001% are actually in use. And all the other old IT companies (IBM, Sun, SGI, etc.) probably are similarly inefficient.

IPv6 will not run out of addresses - it will use 128-bit address space. This is 4 Billion times 4 Billion times 4 Billion times the size of the IPv4 address space. This works out to approximately 665,570,793,348,866,943,898,599 IP addresses per square meter of the surface of the planet Earth. Plenty of addresses for both your toaster and your waffle iron.

More here: http://playground.sun.com/pub/ipng/html/INET-IPng- Paper.html

10 of these ought to be more powerful than anything else that's been built. 1060 processors, 5760gb of RAM.

It would definitely be the world's largest MySQL cluster. Of course, I dobut that anybody would even WANT a cluster that big. Once you get a database that size, you would probably want to custom-tailor your own solution, or not use a traditional database at all. The only databases big enough to warrant this type of power are probably those of the government (ie. the IRS); that being said, the government is probably using an ancient antiquated system which works just fine for their purpose.

You can direct them to Allegro (http://www.allegro.cc), or even pygame (http://pygame.seul.org) if they show an interest past your class. Both of these packages can be set up in Win32 (with some work), and are a great start in C/C++ and Python development. They're free, use free compilers, don't require too many additional libraries/includes, and they have excellent example programs the kids can play with/learn from. They also have support forums geared to beginners, and have very friendly followings willing to help newcomers.

SDL (http://www.libsdl.org) and Java (http://java.sun.com) are less optimal choices. SDL requires a ton of includes, and someetimes has a tricky compiler setup. Java doesn't have terribly much support for game programming, and doesn;t have a great game-support community.

Granted, they're not Klik and Play type programs, but it's useful to know about these things in case a student wants to continue their learning on their own.

This isn't exactly a new view. James Gosling's classic Phase Relationships in the Standardization Process is already 13 years old.

Solaris is far more limiting to specific architectures than Linux is. In fact Solaris/Intel is a real dog, has always had limited hardware compatibility and Sun's Intel boxes are simply too expensive.

You might want to check the pricing on Sun's new Intel servers.

They do seem to bear comparison with Dell at this point.

Have you actually checked the prices for Sun's Linux boxes?

You mean here? $1,995 for a single-proc P III @ 1.4Ghz?

That's the entry price, as soon as you start looking at upgrades and systems with fault tolerant power supplies, RAID etc... then yes... they are expensive. $520 for a second processor!! (just a 1.4Ghz P-III).

Just go to www.pricewatch.com and see what $1,995 can get you.

+3 Insightful? WTF? Did the all the anti-Java FUD /.ers get their mod points today?

First you place the blame on Java as one of the bloat/UI "candies" that are forcing people to upgrade thier PC. Then you say that Java has mostly expanded on the server market. So which is it? They aren't big currently big in the GUI department (although if you go here, you'll see that is changing). So tell me again how Java, which runs mostly on servers, is forcing people to upgrade their PC because of UI bloat?

Or how this is part of this conspiracy since Java is made by a company that doesn't make a desktop PC, a company that until recently didn't even support the x86 architecture very well, a company that makes high-end servers and workstations that have exceeded your "typical" PC mentioned above for years?

I agree that Java does on the server "what was easy to program and cheap to run using Apache/CGI/PHP/Perl/Python". It also does it faster (Python, by about 20%), with more maintainable code (Perl) and more securely (CGI). Apache (and by extension Jakarta) has always worked hand-in hand with Java quite well. But then, there are times when Perl and Python are the better choice, so use the right tool for the job.

Comparing Swing to Flash is like comparing Gnome with HTML. That's right....apples and oranges. Excellent strawman attack but it doesn't work. The two are for totally different UI environments.

Mods, just because you don't know Java or agree with the FUD doesn't make this guys tripe right.

Amaya is written in C. Perhaps you were thinking of Sun's HotJava?

Sure you do, if you try to access them without first calling setAccessible .

However, it's pretty easy to turn that exception off unless there's a SecurityManager installed.

Conclusion? Don't make any java code a security boundary without putting a SecurityManager properly in place. This also implies that java code at security boundaries has trouble being fast, but that's the case with any code at security boundaries.

Why you might make some good theoretical points, some of your assumptions are off. I heartily recommend to you reading Sun's java manpage and searching for the word "default" before making statements about what the default behavior of java is.

By default java will limit the heap size to 64 MB If, as with most modern machines, you have significantly more than 64 MB to devote to user-mode applications, then the default settings will not in fact, as you contend, make performance horrible the instant more than one java application is launched. Also, keep in mind that with java, the JIT can if it wishes to do so move frequently accessed objects so that they are on adjacent pages of memory. This can dramatically reduce paging latency as compared to other code.

As for your points about L2 and L3 instruction caches - I suppose. At the very least, I don't know of any reason why it is obviously false. I'd need experimental confirmation first before I'd be willing to accept this.

I don't think the user's choice of interpreter affects whether your program is Java or not.

In any case, as you say, being able to bypass the access control is unlikely to be useful, safe, or worthwhile other than as (maybe) a security risk.

You were saying?

Access can be controlled by a security manager; but the default for a java application is to allow access.

If you look at Sun's press release about Red Hat you'll see that Red Hat will be including the JVM with their RH Enterprise Linux distributions ... not with Red Hat Linux, and that Sun will only be supporting RH Enterprise Linux. Why? Because Sun still won't license the JVM for redistribution. I'm not saying that Sun is wrong here (it's their toy, they get to choose the license), but this is what has been slowing the acceptance of Java on Linux with many developers. (Except for corporate Java developers -- they love it, and thus, so do I.)

Sun's trying to balance control of Java against market acceptance, and Solaris against Linux. Sun obviously thinks that anyone who wants Java for Linux will go to the effort of downloading it from Sun, while at the same time they get to differentiate Solaris from Linux by including Java. On the other hand, Sun could hardly sell & support Linux on Sun servers without also including Java; this agreement gives them what they want without letting go of their (perceived) control of Java.

I just read the fine print... Suns JVM will only ship on Red Hat's Enterprise Linux Product.

To me it looks like Sun x86 are competing with Sun SPARC with this move.
Who wants to buy a Sun Fire V240 at $6495 when they can this Sun Fire V65x at $4595?

Lets look at the specs:
V240 (SPARC),2U 2*1GHz UltraSPARC3, 1 MB Cache pr.CPU, 2 GB RAM max 8GB, 2 x 36 GB max 4, 4 x1Gb Ethernet, Solaris 8.

V65x (x86),2U 2*3GHz Xeon, 512 KB Cache pr.CPU, 1 GB RAM max 12GB, 1 x 36 GB, max 6, 2 x1Gb Ethernet, Solaris 9 or Linux.

Maybe the SPARC have better "troughput" for some applications, but it looks as if the V65x is better overall especially for CPU intensive tasks.

Since the volume of total SPARC CPU's will go further down as more Sun machines are sold with Intel CPU's they will become even more expensive.

To me it looks like Sun x86 are competing with Sun SPARC with this move.
Who wants to buy a Sun Fire V240 at $6495 when they can this Sun Fire V65x at $4595?

Lets look at the specs:
V240 (SPARC),2U 2*1GHz UltraSPARC3, 1 MB Cache pr.CPU, 2 GB RAM max 8GB, 2 x 36 GB max 4, 4 x1Gb Ethernet, Solaris 8.

V65x (x86),2U 2*3GHz Xeon, 512 KB Cache pr.CPU, 1 GB RAM max 12GB, 1 x 36 GB, max 6, 2 x1Gb Ethernet, Solaris 9 or Linux.

Maybe the SPARC have better "troughput" for some applications, but it looks as if the V65x is better overall especially for CPU intensive tasks.

Since the volume of total SPARC CPU's will go further down as more Sun machines are sold with Intel CPU's they will become even more expensive.

IBM's 1U Server
Sun's 1U Server

At least they are price competitive with IBM. I'm not too sure about Dell but it's a start.

I've actually been looking at Sun's new entry level servers, the v210 and v240 servers.

The v210 starts at $2,995US, and the large configuration, with 2 1Ghz UltraSparc IIIi processors, 2GB of RAM, 2 36GB 10,000RPM SCSI-III drives, and 4 10/100/1000 network intarfaces comes in at $5,795US. I've seen comparible x86-based servers for more than that.

I've actually been looking at Sun's new entry level servers, the v210 and v240 servers.

The v210 starts at $2,995US, and the large configuration, with 2 1Ghz UltraSparc IIIi processors, 2GB of RAM, 2 36GB 10,000RPM SCSI-III drives, and 4 10/100/1000 network intarfaces comes in at $5,795US. I've seen comparible x86-based servers for more than that.

All "New World" Macintoshes use Open Firmware, an IEEE standard which (I think) was originally developed by Sun. You can find more information here.

I hope that the above post is part of an elaborate joke. Otherwise, looking at this and the 455 other messages comprising the debate so far, I don't think /. is about to improve its its position in the 'where to come for Java enlightenment' stakes.

1) Re: swapping. Java memory management will always be superior to that of the OS - OS constraints should never be greater than those applied by the VM. The memory limit of a Java process is defined with the -Xmx=nnn parameter. For production use, this should never be more than the physical memory actually available to the Java process.

2) Re: CPU cache: By the time a CPU executes compiled code, bytecodes are nowhere near the CPU cache (they were never near the instruction cache). The fact that the code was earlier produced from bytecodes is completely irrelevant. Furthermore, bytecode compilation is persistent - compiled code is never destroyed for memory management purposes.

3) Java and C++ optimizations: by definition, a Java JIT compiler can make all the optimizations a static compiler can make, and then some. This is because: a) the bytecode is the semantic equivalent of the source, so all source optimizations can be applied; b) it additionally has access to the complete code base, not just the equivalent of a single source file and c) it has access to the dynamic characteristics of a program, such as "branch taken" metrics, meaning that potentially indefinite refinements of the program structure are possible.

For those that are true seekers after knowledge, I think it is safe to say that your reading time will be better spent with Sun's papers on GC or VM design, starting here, and perhaps comparing mechanisms with those of LISP machines, Dotnet or the Parrot VM.

I also recommend getting up to speed with the new I/O, printing and regexp features found in 1.4 - a good start is Travis's JDK 1.4 tutorial, though it does not cover everything new.
.

The Java Sources!

With the new JSPA, now any body can reimplement compatible Java VM taking benefit of the JCK / RI.

Apache guys fight agains some Sun fellow to obtain this JSPA.

Now we will see if the GNU gurus realy want an open Java or still preffer to get locked on their C++ ... hope classpath will not get stuck again !

Tiger (the new upcoming Java) will be under JSPA. But will RMS and others noticed this is an oportunities to make things moves in the right way ?

Hope so ...

Needless to say the game became every kind of a cesspool you can imagine. There wasn't just one level of cheating but multiple levels of cheating and betrayal.

Oh! Me! Me! Let me tell you how it continued 5 years later. When the Inner Sphere fell into strife and tyranny, in 3050, a huge invader army, sons of exiles actually, came from an unknown direction. Calling themselves the Clans and proving their amazing skills of warfare, they caused great damage to the unprepared Spheroids with their disciplined battle tactics and advanced technology.

Need I go on? =)

public class RunLoop
{
public static void main( String[] args )
{
while ( true )
{
Object o = new Object();
o = null;
}
}
}

....
[GC 606K->94K(1984K), 0.0004234 secs]
.... quizillion times....
[GC 606K->94K(1984K), 0.0004110 secs]
....

1. The VM does free memory in "real-time" ( whatever that may mean )
2. The amortized amount of memory is zero ( it keeps falling back to the base 94K used for the base java classes.

Memory: 127544k/130944k available (1008k kernel code, 412k reserved, 1636k data, 64k init)
DENTRY hash table entries: 262144 (order: 9, 2097152 bytes)
Buffer-cache hash table entries: 131072 (order: 7, 524288 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: Intel Pentium III (Katmai) stepping 03

I do agree that it might be a good idea to allow more tuning to the garbage collector. Instead of telling it "delete, now" though, I'd prefer something along the lines of "force the GC to run now."

You can avoid a lot of these problems in many cases if you use a function like "select()" in a single-threaded program (which, IIRC, Java unfortunately doesn't support).

The standard java NIO APIs support non-blocking IO (which is what select() is).

Umm... No. I read about this too. I haven't been able to dig up the old article and I don't remember if it is part of Apple's 1.4 (which was released well after Sun's 1.4, and thus not there), or continuing under Apple development. It isn't in Sun's releases, and maybe not in any other public release (I haven't noticed improvements on my PowerBook).

Some more info available here: http://java.sun.com/features/2002/03/mac.osx.html

Before any mods take the parent seriously, please realize that this is a troll. He gives himself away in the second paragraph: (emphasis added by me)

While I've never coded in C before I have coded in VB for
fifteen years, and in Java for over ten, I was stunned to see how
poorly C fared compared to these two, more low-level languages.

Others may say he gave himself away even earlier, saying that Perl is a retired language. I'm optimistic, and would like to think Perl is dead, so I won't hold that one against him :)

Setting references to null in Java is not what I would expect from a professional programmer.

1. Your description is a bit too vague, for me to guess with much certainty. I bet you had some finalize methods that were preventing the GC thread from reclaiming your objects fast enough. This situation should be easier to diagnose and prevent than Sun currently makes it, but it isn't really a GC bug. Effective Java has a nice write-up on this problem. If you really think it is a GC bug, try creating a simple test case that demonstrates it. Java has plenty of bugs, but in my experience, trying to construct a simple test case for submission to Bug Parade will often demonstrate that you didn't really understand the problem.
2. This sounds quite a bit like either this bug, or a close cousin. It is quite nasty, but really a bug in the java.lang.String code, and not in the GC.

That verbage is originally from Sun, not Microsoft. They had to include it in the license if they wanted to distribute a JVM. It's a leftover from so much Sun hardware being used in critical situations. I believe that they have removed that requirement from all current implementations (at least I couldn't find it in the current license.

You have to keep in mind that Microsoft can "cheat" a lot of times by preloading DLLs when Windows starts and sharing the loaded libraries between applications. The task manager is very often misleading about the actual memory usage of application.

Hopefully Sun will implement this feature request, at which point you will be able to make an apples to apples comparison.

There is a substantial number of books that cover various J2EE technologies.
Just on Sun's site you can find these lists:
- Java Developer Connection: Books
- The Java Series

What book(s) would you recommend for an experienced C++ developer who wants (or needs) to switch to J2EE development?

There is a substantial number of books that cover various J2EE technologies.
Just on Sun's site you can find these lists:
- Java Developer Connection: Books
- The Java Series

What book(s) would you recommend for an experienced C++ developer who wants (or needs) to switch to J2EE development?

Sun: Nice hardware, very expensive, CDE.

AMD: Commodity hardware, cheap, WinXP.
HP: Intel hardware, very expensive, CDE or WinXP.

This has got to be a troll, albeit a clever one.

Never mainstream? So there is any real chance that hooking up hundreds or thousands of computers in a grid has that possiblity anyway? It may become common in universities, or in some sectors of the Fortune 5000 or certain industries, but its not anything that will be in Mom & Pop shops that constitute a large percentage of our economy, except as something like seti@home.

This is just an inverted version of the "network computing" universe

No. There is no requirement in grid computing to eliminate cetralized servers. What it does is provide a means of making better use of existing resources. If you have to solve the types of problems suitable for grid computing it can be a powerful tool.

The number of problems with this, as compared to using a central server, is incredible.

What is truly incredible is that you would propose doing something blatently stupid and inappropriate with the technology (transaction processing) as a reson why it won't work. You don't try to use your microwave as a toaster, do you?

I rattled off this list in about 30 seconds

Too bad you didn't spend another 30 seconds, you might have figured out some of the advantages.

Better yet, try reading soem of the background material:

IBM
Sun

You've managed to miss the point. Completely. If you read the IBM material and it wasn't clear, try Sun's material.

What use is a CLR standard without an API standard? You can't exactly WORA! It's like coding in C to platform-specific APIs! Or restricting your code to only run on x86.

Fine - so you're in effect targeting a single processor architecture which happens to be a virtual machine, not a real machine. Big whoop! That only solves the least interesting and challenging half of the platform standardisation problem. Java has already solved 99% of it.

Why don't people see this?

You won't find their Windowing code in their or ASP.NET but these are the area's that are going to generate revenue for MS.

Of course... but Sun made all their APIs cross-platform. Why the difference? Because MS needs to entrench its monopoly.

Anyone who doesn't want to support the MS OS/Office monopolies should not be using .NET. Java is equally capable, and more mature, save for some minor language points which are being addressed in JDK 1.5.

There are now ports for FreeBSD, MacOSX and the Mono guys are working a version for Linux.

Once again, a port of the CLR is not much use for without the API. Why not just use Java? Plus there are patent issues with the entire .NET shebang. Java is becoming more and more open all the time. The source code of J2SE 1.5 will be licensed for commercial use at no charge, according to Sun. And the language and all standard APIs are developed under the Java Community Process which includes open source groups like Apache (and one company heavily invested in open source, you might have heard of them - their name begins with I and ends in M).

True platform cross compatibility, plus a typed runtime that was actually designed to provide support for somewhat seemless byte code compilation from multiple languages. Unlike the JVM which really was designed for Java only to run on different platforms.

That's hype. CLR and JVMs are about equal in their ability to run different languages. Neither are perfect.

I've been workin on .NET for a few yrs now, actually with the open source release Rotor designing a functional langauge and have found it rather a joy to use.

Well, I'm sorry but I don't think that provides a good indication of real-world usefulness. "Pure functional languages" like Haskell are niche products that are inherently not suitable for many real-world, high-volume uses, because they don't support single-process interactivity(!) (Unless you implement a non-functional language on top of them and use that instead, which is one heck of a way to waste effort.) That's a pretty fundamental problem, man!

"Impure" functional languages, like Scheme, on the other hand, are fine - but the word "functional" has been stretched so much it's now unclear what it means.

Anyway, as I said, JVMs and the CLR are pretty much equal in terms of language support, so it's a moot point.

Plus MS Research is now supporting quite a few research oriented open source initiatives that will hopefully provide rather novel enhancements in the coming years.

Java is not standing still either. I suspect that Intentional Software (a R&D company - for now - started by a former MS research prodigy, and Gregor Kiczales, inventor of AspectJ) will produce stuff that feeds back into both Java and MS's stable. I don't however see anything which leads to the impression that MS will have a decisive upper hand in future.

Finally, check out www.gotdotnet.com and compare MS's short list of success stories (TWO! AllState and BearStearns) with the huge number of companies out there that have switched to Java or are building their business on Java technology. NET has been in public release (beta or otherwise) for quite a while now - shouldn't they have more success stories by now?

Sun is heavily involved in Grid computing. They provide free multiplatform grid software (including for Linux), case studies, white papers, etc.

They also host an open source project Grid Engine for the software. The software used to be commercial, but Sun bought it and open sourced it, like they did with Open Office.

WTF is the point of all this MONO.NET bullshit? If we wanted to run java apps there are excellent complete, crossplatform, enterprise grade JVMs from IBM, sun, oracle, BEA Jrockit......

Two reasons to want a JVM under .Net. First, although there are a lot of Java VMs out there, production grade VMs are not free. If, for some reason, you already have a good .NET setup, it makes perfect sense to leverage it for the odd Java application, rather than spring for an extra Java VM license.

Second, not all Java apps are 100% Java. That's why we have the Java Native Interface, which lets you call native APIs from Java, and also lets you embed Java modules in native-code applications. (A lot of the programming tools in Sun's Java SDK are JNI apps, for obvious reasons.) Now, unless you're going to get all religious and insist that Java and .NET must never contaminate each other. it makes perfect sense for Java and .NET to interoperate using Ikvm, or something like it. Suppose, for example, your boss says that your next project must run under .NET, but won't give you time to port all your Java classes. Or more generally, suppose you're just open minded enough to take the best of both platforms.

apple has the best language support if you ask me, so this shouldnt be a problem at all. you can always use keycaps.