Java To Be Opened For Christmas?

MBCook writes "At the Oracle OpenWorld conference, Sun's CEO Jonathan Schwartz announced on Wednesday morning that Java would be opened within 30-60 days, which would would mean about Christmas Day at the latest. Sun first announced they would do this back in May at JavaOne but didn't give a date. We've seen rumblings before on this topic. Schwartz also commented on the companies Sun Fire servers, Sun's relationship with Oracle, and general trends."

Comments

All I want for Christmas...

[EmperorKagato]

Is Java-S-E.

Re:All I want for Christmas...

[Anonymous Coward]

Java SE is not just for christmas.. it's for life.

64-bit

[compm375]

Now maybe we can have a Java plug-in for 64-bit browsers.

Re:64-bit

[EmperorKagato]

or Java that utilizes the 64 bit arch as well as take advantage of dual core processing and hyperthreading.

Re:64-bit

[Anonymous Coward]

I'd settle for a Java that doesn't make my machine run slower than a frozen slug.

Re:64-bit

[thebluesgnr]

We already have one.

http://packages.debian.org/unstable/net/gcjwebplug in

[alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc]

Re:64-bit

[gerrysteele]

Maybe you need a new machine? Or perhaps a new operating system

Re:64-bit

[brunes69]

I have never hard the GCJ web plugin actually *work* for a single site I visit. All it seems to know how to do is pop up a window with exceptions in it.

Re:64-bit

[compm375]

True, there are gcj and blackdown, but I was referring to a Sun Java that had a 64-bit browser plug-in. I thought it was implied given an open Sun Java was what the article is about. I appreciate the efforts going into non-Sun Java implementations, but as of now they don't quite have full compatibility.

Re:64-bit

[cnettel]

What do you have in mind? You might do separate heaps on a per-socket basis, rather than per-thread or common to all (the most common options today), but the JVM itself is not exactly something you easily make parallel.

Re:64-bit

[Anonymous Coward]

What else does it need to do to support dual cores? It looks like it's working fine for me here.

Re:64-bit

[EmperorKagato]

That's what I thought until I ran a program I created that seem to only utilize one of the processors.

Re:64-bit

[Anonymous Coward]

Did it use threads? I'm using jboss spinning off about a dozen services and it looks like they're pretty equally balanced between my cores.

Re:64-bit

[CRCulver]

It's also got serious security flaws.

Re:64-bit

[gameforge]

We need one less programming language, that's for certain.

Re:64-bit

[TheRaven64]

Umm, the very first platform Java ran on was Solaris, running on multiple 64-bit SPARC CPUs.

Re:64-bit

[Anonymous Coward]

I was at JavaONE 2 years ago and asked about this. Apparently Sun was planning to get this done for Java 7 (Dolphin). It's being held up so that their coders can scrap the client and server Hotspot compilers and create a single tiered compilation VM. From what I understand the two compilers had a lot of code duplication and stuff that they wanted to sort out.

Re:64-bit

[JebusIsLord]

Uhm, did you start a second thread in your application? Works fine from here.

Re:64-bit

[CastrTroy]

Which is why I think Hyperthreading is a big load a of crap. Whenever I seem to need a little extra power, my computer seems to be stuck around 50% because whoever wrote the program (VB.Net Compiler) doesn't think that making threads is a good idea. Sure Hyperthreading will speed up a few things, but for the most part it just means I end up waiting longer because most of the software out there wasn't written to take advantage of the fact that people may have multiple processors. But I don't really blame them. I took a parallel programming course in University, and it was a lot harder than programming in serial.

Re:64-bit

[CastrTroy]

But is it going to be Open source like OO.o is open source? The problem (AFAIK) with OO.o is that they have a huge code base that nobody understands, and that it's hard to actually get them to accept changes from outside their special little group of programmers. I hope that open sourcing Java ends up being better than open sourcing StarOffice ended up.

Re:64-bit

[MaggieL]

We need one less programming language, that's for certain.
OK...pick either VB or PHP to hit the dumper. And then everybody who think's he's a programmer who knows only the one that gets GCed.

Re:64-bit

[VGPowerlord]

I take it that the parallel programming class didn't mention that a program with a GUI has multiple threads, simply because the GUI needs one for event dispatching?

Re:64-bit

[EvanED]

I take it that your GUI programming class didn't teach you that it's very possible to make a program that uses a GUI that's only single threaded?

I dunno if that's the case in Java, but any "hello world" Win32 program is certainly single-threaded.

Re:64-bit

[VGPowerlord]

It's possible, but not practical for real world applications.

Re:64-bit

[EvanED]

I would argue that it's as practical as any other application, if not moreso.

Re:64-bit

[tepples]

Maybe you need a new machine?

Are you buying?

Re:64-bit

[Cyberax]

Java worked on 64-bit systems from the day one. And it supports massively parallel (32 cores!) Sun Niagara CPUs.

Re:64-bit

[Westley]

Only if you don't mind your GUI completely freezing if you make a blocking call of any description.

Re:64-bit

[EvanED]

True, but in most interactive apps those situations pass within a couple seconds. (Even if they don't, depending on the reason it's "blocking", you still might be able to make forward progress. For instance, if you're just doing computation, you can periodically check for new messages and dispatch them while putting your computation on hold. This won't work if you're actually blocked by the OS of course.) Also, most interactive apps are almost completely waiting for user input anyway. So if you don't multithread your program it will be frustrating to use because it will occasionally make you sit there, but it probably won't take *too* much longer to do what you're doing. But if you're doing some longer-running process (compilation, scientific computation, analysis, simulation, etc.), having a single thread instead of multiple threads could substantially increase your running time if you're on the right hardware.

So actually I'm gonna pull off of my original statement a little... if you're on a uniprocessor, the difference between your long-running process being multithreaded or not isn't gonna be too much. So multithreading it becomes a lot less important. So going to multiprocessor/core benefits parallel computationally-intensive programs a lot, but interactive applications little. (SMT would depend on the workload of the parallel app where it falls in the continuum.)

Re:64-bit

[todorb]

there are not many compilers i know of, that decide by themselves to make threads out of some parts of code. and exactly why do you think you're going to "end up waiting longer"? you just have more execution units in a HT processor. by "took a parallel programming course" do you mean that you finished it successfully? from your comment i doubt it very much.

Re:64-bit

[EsbenMoseHansen]

The problem (AFAIK) with OO.o is that they have a huge code base that nobody understands, and that it's hard to actually get them to accept changes from outside their special little group of programmers.

If it is opensource, and someone is really stiffling the progress.... it can be forked. gcc and XFree are 2 examples of how to do this.

But really, Java has so many flaws, it is only useful for backward compability, unless someone is willing to fix some of the more fundamental flaws. Like getting rid of primitive types, stop throwing the type information away for templated, sorry, generic types, getting support for resource management (where resource != memory). I could go on, but I won't, since it is friday and I am a happy person :)

Re:64-bit

[ivoras]

I hope people remember this thread a few years from now. People who don't contribute to Java now (and they can, the development process is open enough) will certainly not contribute when few words in the license is changed, and if they do, it's likely Java will get fragmented because of it (see Firefox/Iceweasel debacle - who wants applications that run only on Debian's "distribution" of Java?).

Re:64-bit

[ajs318]

Did you remember to set CONFIG_SMP=y?

Re:64-bit

[ajs318]

Which is why I came up with a self-parallelising architecture on the back of an envelope. I got the instruction length down to 16 bits (usually - some instructions are 80 bits), so allowing 4 instructions to be packed into a 64-bit word. And those four could all be executed in parallel, so long as none of them depends on an answer from a previous instruction (for an operand, or in its condition field) and at most two of them require a bus access (one in each direction; all reads are done on the tick and all writes on the tock). It should be possible to optimise in the pipeline, even accounting for conditionals that won't actually be executed. In practice I expect most instructions will execute always, and a fair number will be Last Successful or Last Failed.

Re:64-bit

[ajs318]

Perhaps Debian can call their Java fork "Rosie" ?

Re:64-bit

[Octorian]

Um, that kinda already exists. Sun has a 64-bit version of Java for SPARC *and* x86-64, and has for quite some time. (they don't have a 64-bit browser plugin, but they have 64-bit *everything else*)

Of course SPARC isn't a braindead architecture that sucks less in 64-bit mode, so Solaris doesn't actually need to run the entire userland as 64-bit code. As such, even on 64-bit Solaris, most of your apps are still 32-bit. (which makes sense, since 64-bit code can be wasteful on system resources if your app doesn't actually need 64-bit pointers)

Re:64-bit

[mackyrae]

VB. It's not even a real language. It's just clicking around.

Re:64-bit

[CastrTroy]

Since you asked, I actually got an A+ in the course. The problem with the extra execution units in hyperthreading is that they only run at half the speed of the single execution unit if you turn the hyperthreading off. So, for applications that aren't written to take advantage of the extra processing unit(s), you will actually experience a slow down. Since a large majority of desktop computers only had a single execution unit, up until a couple years ago when HT and DualCore started to become popular, most programs were only programmed to work on one processor. This is especially true because of the extra complexity required in writing programs that are parallel. The algorithms are different, and the way you think about problems is different. There are currently some languages and libraries that make this process a lot easier, but they aren't widely used, because like I pointed out, people haven't really seen much of a use for them. I think that as multiprocessors become more common, and if intel ever does release their 80 core processor, that we will start to see a big move towards parallel programming. Until then all my old software runs slower on hyperthreaded mode.

Re:64-bit

[GigsVT]

Why would anyone use Java unless forced to by some crappy web site?

For 99.9% of the world, the plugin is all that matters.

Re:64-bit

[cb0nd]

Well... VB is Turing complete. Heck... It still sucks!

Re:64-bit

[Reverend528]

I have never hard the GCJ web plugin actually *work* for a single site I visit. All it seems to know how to do is pop up a window with exceptions in it.

Sounds like java to me.

Re:64-bit

[Anonymous Coward]

I think you misunderstand how HT works.

On any of the netburst P4's there were multiple execution units, be they HT or not. There was also a clever scheduler that would take the instruction stream (from a single thread) and figure out the interdependancies between the instructions - so that instructions could be executed in parallel on the multiple execution units. This helped hide the hideous latency problems with the netburst architecture as the instruction pipeline was so long.

What intel realised was that many of these extra execution units were infact idle much of the time because there weren't enough independant instructions coming through on a typical thread - even with their clever compilers. So they discovered that they could actually simply (well probably not) add another scheduler to the processor that used these spare slots on the existing execution units. All it took was something like a 5% increace in transistor count and they got the capability of running another thread on the same processor - so this was cheap in comparison. Also AFAIK that's why it's not there on the Core processors - they don't have the same super long pipelines so there is way less benefit.

So in theory turning HT on makes the machine simply seem to run faster as it has a second logical processor. The units themselves don't run at half the speed though if you turn hyperthreading off, they run at the same speed.

So on the face of it HT should be a win-win situation. However there are gotcha's involved. Firstly there is cache - both the threads share the same cache. This is made even worse by windows by default creating threads that are on 1MB memory boundaries - which means that they actually share cache lines in cache because of the way the aliasing works (why they thought this was a good idea in the first place I don't know). This can make HT much much slower than non HT but is easy to get around.

Also things that do busy-waiting loops rather than using OS sleep (something you shouldn't ever do of course) will flood the execution units and so take away from the non-waiting threads capacity.

These are almost certainally why your stuff runs slower in HT mode - it was written without considering HT in the fisrt place.

Re:64-bit

[thePowerOfGrayskull]

Whenever I seem to need a little extra power, my computer seems to be stuck around 50% because whoever wrote the program (VB.Net Compiler) doesn't think that making threads is a good idea.

I'm sorry -- I freely admit that this may be my ignorance of vb.net shining through -- but did you just blame the compiler for not putting threading logic in your code? Am I missing something here?

Re:64-bit

[thePowerOfGrayskull]

Why would anyone use Java unless forced to by some crappy web site?

Good morning, did you know there's a whole world of server-side programming out there?

For 99.9% of the world, the plugin is all that matters.

I think you meant: For 99.9% of the end users, the plugin is all that matters.

Re:64-bit

[GigsVT]

Good morning, did you know there's a whole world of server-side programming out there?

And what does the world of PHP and ASP.net have to do with some crappy browser plugin that sites from 1998 use?

Re:64-bit

[CastrTroy]

I'm not talking about the output program from the compiler, but rather the compiler executing. When my compiler executes, it only uses up 50% of the cpu, making the act of compiling the code take twice as long, had it used 100% of the processor.

Re:64-bit

[thePowerOfGrayskull]

Do you still use PHP? How quaint...

Re:64-bit

[thePowerOfGrayskull]

Ahh, gotchya. I misunderstood, my bad.

Re:64-bit

[eosp]

So is Brainfuck. But that's a bit cleaner.

Re:64-bit

[FishWithAHammer]

Eh..VB is really not all that bad. VB6 wasn't bad, but VB.NET has gotten surprisingly good. (The fact that it's the exact same thing as C# though with a different syntax certainly doesn't hurt.)

Re:64-bit

[Octorian]

Not always, actually. Thanks to tack-on systems like "Java Web Start", sites can provide *real* locally-running applications through a delivery mechanism that makes them launch from web sites. I've actually run into some applications (like web conferencing software) that use this approach, and it works rather well.

Re:64-bit

[Westley]

If you *ever* touch the network, you really shouldn't do so in the UI thread. A good example of the problem is Firefox, which will hang completely if some Javascript makes a network request. That's a really nasty situation to be in.

The difference in user experience between a properly written multi-threaded app and a single-threaded app which doesn't take great care not to make blocking calls is vast, IMO. That doesn't depend on whether or not you've got multiple processors - it's just a case of blocking calls not preventing the UI from working. Yes, most of the time many apps will be waiting for user input - but the computer doesn't mind that, whereas users really *do* mind it when they can't even resize or close a window because a server they're talking to hasn't responded yet.

Jon

Re:64-bit

[thePowerOfGrayskull]

I wish that were more widely used -- generally offensiveness aside, the GP poster indirectly raised a valid point. The general perception of Java has suffered greatly because of early experiences that people have had, and continued (though dwindling) web-site usage that relies on plugins.

Re:64-bit

[DragonWriter]

If it is opensource, and someone is really stiffling the progress.... it can be forked.

I'm not sure how that addresses the main problem GP points to: "The problem (AFAIK) with OO.o is that they have a huge code base that nobody understands"

Re:64-bit

[Mr. Slippery]

I take it that the parallel programming class didn't mention that a program with a GUI has multiple threads, simply because the GUI needs one for event dispatching?

Ah, you kids today and your multi-threads GUI programs.

It's entirely possible - indeed, was once common - to use an event loop/callback scheme to run a GUI program in a single thread. Obviously non-blocking calls must be used.

Threading only started to become common with the release of Pthreads, in the mid-1990s. (Of course it existed long before then!) I don't do much GUI programming but I would not be surprised if back in the days of X11R4, the X libraries weren't even thread-safe.

Re:64-bit

[EsbenMoseHansen]

I'm not sure how that addresses the main problem GP points to: "The problem (AFAIK) with OO.o is that they have a huge code base that nobody understands"

I didn't address it since it is obviously nonsense (if noone could understand it, noone could maintain it. If someone can learn it, then someone could fork it.) If you want to work on a nicely coded office suite, take a look at KOffice. Or maybe Abiword, I don't know that one.

Re:64-bit

[mackyrae]

The fact that M$ decided to make VB6 break by making VB.net is just lovely, isn't it?

Re:64-bit

[Anonymous Coward]

I pick VB. You can actually do something useful with PHP. :)

Co-ffeee...

[Thisfox]

Mmmm... Java with the lid off, so we can see the coffee inside...

Sorry, couldn't resist, must have had too much caffiene thismorning...

Re:Co-ffeee...

[Captain Splendid]

Which would hopefully mean Java that isn't horribly bloated and slow as molasses?

Between Azureus and a few useful web applets, I use Java far more than I'd like, as it's the slowest thing on my PC (3ghz/1GB RAM). Would definitely like to see it slimmed down.

Re:Co-ffeee...

[Anonymous Coward]

1999 called, it wanted its lame comment back.

Re:Co-ffeee...

[Captain Splendid]

Listen dude, I didn't say it wasn't better, but it's far from from fucking svelte.

Re:Co-ffeee...

[darkchubs]

dude, Java makes Ana Nicole Smith look like Nicole Richie on crystal meth

Re:Co-ffeee...

[kevin_conaway]

Between Azureus and a few useful web applets, I use Java far more than I'd like, as it's the slowest thing on my PC (3ghz/1GB RAM). Would definitely like to see it slimmed down.

Using Azureus as an example of memory problems in Java is like using Firefox as an example of memory problems in C++

Re:Co-ffeee...

[NoCorR]

Why was this modded Flamebait? It's a perfectly valid question. Java is bloated. It takes 5+ minutes just to load up a Java app on my machine. I'm reminded of something I heard somewhere, "Saying Java is good because it works on all platforms is like saying anal is good because it works on both sexes."

Re:Co-ffeee...

[mcpkaaos]

Have you seen Anna Nicole Smith recently? She already looks like herself on crystal meth.

Re:Co-ffeee...

[ahaning]

Good ol' Bash...

http://bash.org/?338364

Re:Co-ffeee...

[Anonymous Coward]

I don't know about your hardware, but a biggish app like netbeans loads in ~20-30 seconds (which still sucks cock compared to, say, the ~4 second MS Visual Studio 2005).
Do-nothing hello worlds in swing take a noticeably long time to come up. It only gets worse the more complex the app, and the slower the hardware.

A pox on all those who foist Java Swing apps on their users.

Re:Co-ffeee...

[Shawn is an Asshole]

5 minutes? What the hell are you running? Have you used a Java program since 1998?

I'll do a test right now, with Java 1.6b2 and Eclipse 3.2 with an Athlon 64: 12 seconds to the workbench.

Yep, that's a long time. Keep in mind Eclipse is a heavy app and I do have many extensions installed. Other Java apps I use regularly, such as pdftk (command line) come up instantly and work very fast.

Properly written Java apps are not slow, though if they use Swing they look hideous.

Re:Co-ffeee...

[Anonymous Coward]

I know you weren't trying to be funny. But you probably picked java's flagship app and not C++'s , but definately in the top end for C++. And they both have memory problems. That would seem to indicate that if these flagship products have these type of problems there is probably a weakness in the language. If either language were so awsome we would not have memory problems. It's 2006 and we still talk about memory problems. No more blaming the programmers, they already have proven that you give them enough rope they will hang themselves. We now need a new language or a current one re-designed so memory leaks are a thing of the past. Or a much improved garbage collector.

Re:Co-ffeee...

[Anonymous Coward]

1995 called, it wants its joke back.

Re:Co-ffeee...

[NoCorR]

I meant when I load Java apps within Firefox. It takes awhile. But running Java apps themselves doesn't talk long at all. Just embedded. Guess I should've specified. :D

Re:Co-ffeee...

[tkinnun0]

Guess you should've specified whether it's your network connection or harddrive that sucks, as well...

Re:Co-ffeee...

[Anonymous Coward]

"5 minutes? What the hell are you running? Have you used a Java program since 1998?"
Properly written Java apps are not slow, though if they use Swing they look hideous.

Properly written Swing apps look great. Guess you haven't seen one since 1998!

Re:Co-ffeee...

[rHBa]

At last FairTrade Coffee

License

[Tribbin]

Under what license?

Re:License

[jonwil]

Most likely they will use the same license as they used for OpenSolaris.

Re:License

[Ajehals]

The article only says it will be an OSI Approved License and I would suggest that that probably means the CCDL,

Re:License

[4e617474]

All it really tells us is that it will be one of these. I think you're probably right, but I have my doubts that they've even firmly decided on it yet. They've been holding off on announcing the How and When since May, and now they've announced the When.

Re:License

[squiggleslash]

It's worth pointing out that Jonathan Schwarz has gone out of his way to make it plain the GPL is being considered as a possible license. The main issue I think Sun has is that they prefer GPL3, with its patent retaliation clauses, to GPL2. GPL3 hasn't been released yet, and thus far is fairly controvertial (For reasons I continue to find bizarre.)

heresy!

[Phil246]

there is no such thing as too much caffeine :)

Re:heresy!

[N3Roaster]

Sure there is. Personally, I hit my limit with 20 shots of espresso within 2 hours (why yes, I do get paid to drink coffee). You can also overdose on caffeine, but not just from drinking coffee.

Re:heresy!

[Anonymous Coward]

thats why I get mine here:
https://www1.fishersci.com/Coupon?cid=1336&gid=813 03

Re:heresy!

[Anonymous Coward]

or you could get it here http://www.bodybuilding.com/store/sf/caffeine.html in capsule form in smaller quantities for almost half the cost and spend the extra on ephedrine hcl http://www.bodybuilding.com/store/mp/vaso.html

Talk about getting twitchy.

Re:heresy!

[RobertLTux]

well as you reach ~ 5 grams you will find out what "too much" means (starts with the shakes and a "bad trip" and ends with a coronary infarction)
do yourself a favour don't buy the tablets in bulk

Don't be cheap...

[__aaclcg7560]

If I'm getting java for Christmas, it should be gift wrapped. An espresso machine would be nice too.

Re:Don't be cheap...

[pilgrim23]

Better Late` ....then never?

How many days are in your Java?

[DumbSwede]

Java would be opened with 30-60 days

within methinks

Re:How many days are in your Java?

[Reverend528]

30-60 days

The time difference depends on whether or not the garbage collector runs during that time.

Re:How many days are in your Java?

[rjolly]

You're joking, but I've been able to make it spend 12 hours over 24 in the GC for real : http://raphael.jolly.free.fr/text/gc.png (ok it was a tricky symbolic computation, and this is a very very special case just below the heap space limit)

Don't get yer hopes up

[jmorris42]

I'll believe it when it happens. My money is on them releasing under a horrid unfree license and calling it Open Source.

But at this point it really doesn't matter anymore. GCJ already builds many major Java based apps into either Java bytecode or native executables and has long since passed the point where development would be hindered by a Open Source/Free Software release of Sun's version.

GCJ is now bringing a lot more to the table than just cloning the Sun stuff. Sun would never do native executables because it doesn't fit into their 'vision.' The JVM and Write Once Debug Everywhere has no real place in the Free Software world. In the Free world portability comes from automake/autoconf and doesn't need to pay the emulation overhead of a virtual machine or any of the other problems. Problems like each major Java app tending to bring along an entire JVM and set of libraries to solve compatibility issues.

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

Re:Don't get yer hopes up

[Kjella]

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

Just on a wild guess, since C/C++ doesn't target a VM it'd be like saying "we can get assembler code from C, why can't we get C from assembler code?" Going from byte code is easy (well, not really but...) since eventually the byte code has to run on actual hardware, but I don't think there's any good reverse mapping. In the end, I think you'd end up building a x86 VM inside the Java VM, which would have some terrible overhead.

Re:Don't get yer hopes up

[brunes69]

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode?

No.

If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

Mono can already do all of this - mono can run Java apps in it's CIL VM, and Java apps can talk to mono apps.

mono can't build Java code to CIL though, it doesn't understand the syntax. http://www.mono-project.com/Java.

Re:Don't get yer hopes up

[RAMMS EIN]

``In the end, I think you'd end up building a x86 VM inside the Java VM''

Not really. GCC generates x86 code in the backend, which operates on some intermediate language. If the same intermediate language is generated from the Java frontend and the C frontend, and the Java bytecode backend handles that full language, it would be possible to compile C to Java bytecode.

Re:Don't get yer hopes up

[kevin_conaway]

GCJ is now bringing a lot more to the table than just cloning the Sun stuff. Sun would never do native executables because it doesn't fit into their 'vision.' The JVM and Write Once Debug Everywhere has no real place in the Free Software world.

WODE is a silly myth promoted by people with an axe to grind, usually those who have no real world experience with Java. Its extremely easy to write portable code in java, but java won't stop you from writing unportable code, just like any other language.

In the Free world portability comes from automake/autoconf and doesn't need to pay the emulation overhead of a virtual machine or any of the other problems. Problems like each major Java app tending to bring along an entire JVM and set of libraries to solve compatibility issues.

HA! Portability provided you don't need to port to windows.

The "overheard" you speak of is largely irrelevant and has been for quite some time due to advances in computing power.

Re:Don't get yer hopes up

[AnyoneEB]

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

The problem with that is Java bytecode assumes access to the Java class library and .NET bytecode assumes access to the .NET library. You could probably make a lot of 1:1 connections between the two, but why bother when you have JVMs and Mono on multiple platforms. Also, I thought remembered seeing something about Mono being able to interface with Java somehow. Am I imagining things or does someone know what I am talking about?

Re:Don't get yer hopes up

[DeadMeat (TM)]

If the same intermediate language is generated from the Java frontend and the C frontend

It isn't, if you're targetting bytecode. Bytecode is handled as a special case which bypasses GCC's RTL representation.

Since the JVM doesn't allow arbitrary access to memory, it's not feasible to make a Java bytecode backend for GCC. (Java bytecode is Turing complete, so it's technically possible; but you'd have to resort to ugly hacks like representing memory as a gigantic, flat array of bytes.)

Re:Don't get yer hopes up

[Anonymous Coward]

Apparently you've heard of the CLR (and MSIL)?

http://www.gotdotnet.com/team/clr/about_clr.aspx
http://www.codeguru.com/csharp/.net/net_general/il /article.php/c4635/

Re:Don't get yer hopes up

[petermgreen]

If the same intermediate language is generated from the Java frontend and the C frontend, and the Java bytecode backend handles that full language, it would be possible to compile C to Java bytecode.

my understanding was it was more like

java-->java bytecode-->GCC internal-->native code

the trouble with java bytecode is that if you wan't it to run on suns vm and certainly if you wan't it to run in any kind of restricted environment it has to pass the bytecode verifier. Short of essentially having an emulated main ram with a C heap inside it (possible but almost certainly not good for performance) passing the bytecode verifier with something compiled from C would be pretty damn hard.

Re:Don't get yer hopes up

[alphamugwump]

take a look at this

Actually, somebody wrote a java backend for gcc. Problem is, RMS didn't want it in. The idea was, java bytecode might be used as an intermediate language, so that a manufacturer of proprietary hardware could write a proprietary bytecode-to-machine language compiler for their architecture, and then take advantage of the nice GCC toolchain to promote their proprietary stuff.

Now, this seems a little paranoid to me, but there you have it. However, the little known mono competitor, dotGNU claims to have a c to .net compiler, and will eventually suppor java too. might be worth checking out.

Re:Don't get yer hopes up

[Anonymous Coward]

GCJ is now bringing a lot more to the table than just cloning the Sun stuff.
You have got to be kidding me! GCJ is about the biggest Java turnoff for newbies there is. I've been starting with Java somewhere last year and I'm very enthousiastic about it since I really dig the language and the things it provides. What I don't like (I hate it with a passion) is that horrible OSS POS excuse for the real thing.

Tough words, I know. Just goto the Java tutorial and start learning. Eventually you'll come across several examples which do not work. Not even now at this very moment. When I started out those same examples didn't work and I was wondering what the heck was wrong. Surely not the examples themselves.. Only thanks to my Solaris box (or better put: Other Java environment) did I found out that it was gcj which was to blame. Yeah, great environment when it can't even fulfill basic tutorial examples.

Another thing.. I have spend a lot of time on Java usenet groups and Java IRC channels. And guess what? The first thing we ask people when they have problems using Java on Linux is: "What jvm are you using? Are you using gcj by any chance? Please run "java -version"" and when the outcome is gcj we tell them to ditch the piece of shit and get the official JVM from Sun. And yes; in 8 out of 10 cases (very broad yet educated guess) the problems are solved.

So please... give me a break and don't come with this nonsense. gcj isn't Java compatible, has never been Java compatible and most definatly can't keep up with the current pase one single bit.

I really do not look forward to Sun opening up Java since I already saw what might happen when looking at GCJ. The only thing I do hope is that Linux distributors will now finally ship the official JRE with the several environments so that beginning Java enthousiasts won't have to be turned down by official example code not working on their environments.

Re:Don't get yer hopes up

[jmorris42]

> So please... give me a break and don't come with this nonsense. gcj isn't Java compatible, has never
> been Java compatible and most definatly can't keep up with the current pase one single bit.

And I suspect the GCJ developers would agree with your criticisms but reply thus:

"Yes, GCJ isn't complete yet and doesn't run many programs yet. On the other hand we are continuing to work on it and welcome any and all assistance."

The distro maintainers who ship GCJ as the default Java would probably say: "We ship Free Software. GCJ is the only solution to the Java problem available. It runs all of the Java applications we support."

Especially RedHat, they have sunk tons of resources into GCJ because it was the only way around several thorny problems where careless/thoughtless developers wrote key components in a language that had no Free implementation. Of course politics was at the root of most. OO.o added a dependency on Java for the new DB component.... no suprise most of the development was by Sun developers. Eclipse started life as a Java SDK, no suprise it was written in Java.

Go look through Fedora and Fedora Extras for Java based apps. They all run using GCJ because Sun's Java is forbidden by the bylaws of the Fedora Project on the grounds of it being non-Free.

Re:Don't get yer hopes up

[jasondlee]

The JVM and Write Once Debug Everywhere has no real place in the Free Software world.

How did you come to that conclusion?

This question brought to you by the letters Q, E, and D.

Re:Don't get yer hopes up

[Spikeles]

WODE is a silly myth promoted by people with an axe to grind, usually those who have no real world experience with Java. Its extremely easy to write portable code in java, but java won't stop you from writing unportable code, just like any other language.

It's true that you can write portable code in Java, just like you can write portable code in C/C++, but you can't get the program to actually DO anything usefull. And when you try you have to end up debugging it. The easiest example i can think of right now is trying to open a .PDF file. Have you ever tried to write portable code to make Java tell the system to load a PDF file using the default executable handler?

I have worked on shrinked wrap software that was intended to run on both Linux and Windows, and i can tell you that there are little bugs that crop up now and then due to inconsistent handling, rendering issues, font issues, and especially in the way the Look and feels work. Granted it's not as bad as most people think and mostly it's bugs in Java's default libraries, but there ARE issues, and you shouldn't just dismiss them with a wave of the hand just because you have not had an occasion to experience one

I have looked at Java SE 6, and they make great strides to solve the non-portable issues ( the disk free/left and desktop integration is a good example ), but the fact is that the Virtual Machine cannot always hide all the platform quirks, and sometimes you need to "debug" the code and write a workaround for a specific platform.

The "overheard" you speak of is largely irrelevant and has been for quite some time due to advances in computing power

If you mean "overhead" then that too is debateable and i'll take the bait.
Java IS slow. There is no doubt about it. Any chance to remove overhead should be taken. Yes it has the JIT ( which is quite good for servers ), but as i mentioned earlier, we develop shrink wrap desktop software which suffers from horrible performance issues relating directly to JIT, GC, and Swing. Yes, we have profiled it, and optimized it, but the problems are still there. The biggest advantage compling to native code using GCJ, is that of pipelining and cache hits when the instruction code is executed by the CPU, thereby reducing overhead. In performance critical apps ( like a desktop app, that needs microsecond response times ), every little bit of overhead we can remove is crucial.

I look forward to Java SE 6, the new features should help with some of my concerns. And as a final note, ask anyone who has actually done real world apps in Java, they will tell you that Java has it's problems.. but like all languages, is has good points too. I don't bash Java too much, i think we need to highlight it's inadequacies and it's benifits, and not just be evangelical sheep who won't listen to any critism of their holy language.

Re:Don't get yer hopes up

[tonigonenstein]

GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode?

Sure. There are already a few projects aiming to do just that. You can find a partial list here.

Re:Don't get yer hopes up

[tepples]

In the Free world portability comes from automake/autoconf

HA! Portability provided you don't need to port to windows.

Ideally, in the Free world, windows is ReactOS, whose userland is based on the work of the Wine project, but the maturity and user base are not there yet.

Re:Don't get yer hopes up

[popeyethesailor]

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

I know it's too late for anyone to read anyway - Managed C++ in the Microsoft world does something very similar. However, there're certain limitations that come into the picture when targeting byte-code. It works reasonably well, and is a choice for people migrating into the managed code world with a large C++ codebase. For converting C# code to Java and vice versa, checkout IKVM. It's an impressive piece of tech; folks have even converted Eclipse to run on Mono.

Re:Don't get yer hopes up

[EvanED]

It's true that you can write portable code in Java, just like you can write portable code in C/C++, but you can't get the program to actually DO anything usefull. And when you try you have to end up debugging it.

I have worked on shrinked wrap software that was intended to run on both Linux and Windows, and i can tell you that there are little bugs that crop up now and then due to inconsistent handling, rendering issues, font issues, and especially in the way the Look and feels work. Granted it's not as bad as most people think and mostly it's bugs in Java's default libraries, but there ARE issues, and you shouldn't just dismiss them with a wave of the hand just because you have not had an occasion to experience one

I just want to offer a counterpoint to this... I did Java development at IBM for a summer internship. We were doing server-side stuff (which would, granted, bypass the most difficult platform-specific stuff, the GUI), but we developed on Windows on just typical laptops. The final target for the program was s390 Linux. Change of OS, change of architecture, even change of character set from ASCII to EBCDIC. You'd be hard pressed to find a larger platform transition. We had to make one change to the program to get it to run as well on there as it did on our laptops. I was quite impressed.

Re:Don't get yer hopes up

[zlogic]

I think the OP was saying something more like "If we can make ASM code from C, why can't we get ASM code from Perl?"

Re:Don't get yer hopes up

[Jesus_666]

GCJ is now bringing a lot more to the table than just cloning the Sun stuff. Sun would never do native executables because it doesn't fit into their 'vision.' The JVM and Write Once Debug Everywhere has no real place in the Free Software world.

Except for those projects who don't want to fight with managing target platforms. Unlike most C++ libraries Java runs somewhat decently everywhere. No working around OS-specific compiler quirks, GTK not using Aqua on MacOS or Windows not supporting half of the libraries the other platforms depend on.


In the Free world portability comes from automake/autoconf and doesn't need to pay the emulation overhead of a virtual machine or any of the other problems. Problems like each major Java app tending to bring along an entire JVM and set of libraries to solve compatibility issues.

You mean trying to learn M4 is in any way productive? Okay, there are alternatives (for example KDE made the move to the vastly superior CMake). Of course if you use, for example, libtdl, Boost and CMake you end up depending on three separate build systems when you really only need one. Much better than having a comprehensive class library from the start, yeah.

Note: I'm not a Java geek; in my opinion the language is far too verbose. However, if you want to support many architectures it is better than many other languages.

Re:Don't get yer hopes up

[LarsWestergren]

The JVM and Write Once Debug Everywhere has no real place in the Free Software world.

Sez you. In the real world, java has been the language with the most projects on Sourceforge for quite some time. There are also many other repositories. So you don't speak for the majority.

In the Free world portability comes from automake/autoconf and doesn't need to pay the emulation overhead of a virtual machine or any of the other problems.

Again, the majority of languages today, including the open source world, target a virtual machine or an script interpretor. JVM, Mono, Python virtual machine, Parrot, the Lisp virtual machine, and all the scripting languages - Ruby, Javascript, PHP, Lua...oh what the hell, all of them.

Problems like each major Java app tending to bring along an entire JVM and set of libraries to solve compatibility issues.

Apps coming with their own virtual machine rather uncommon today. And what application doesn't come with a set of libraries today?

Re:Don't get yer hopes up

[smash]

The idea was, java bytecode might be used as an intermediate language, so that a manufacturer of proprietary hardware could write a proprietary bytecode-to-machine language compiler for their architecture, and then take advantage of the nice GCC toolchain to promote their proprietary stuff.

So instead, they can just for example write an x86 front end for their hardware and recompile/interpret that at runtime and leverage the gcc toolchain? Like Itanium perhaps? Or even modern x86 cpus...

Braindamaged thinking if you ask me, I mean, they could do that with any of the platforms GCC officially supports, not just the Java virtual machine...

Re:Don't get yer hopes up

[owlstead]

Yup, almost by definition, Java VM only uses references, not pointers as such. Pointer arithmetic is not supported. Now you *could* rewrite every C/C++ app and toss all the pointers out, but don't expect too much support from anybody... Java bytecode lives on a rather higher level than normal machine code. For instance, exceptions are handled in Java bytecode, while the x86 instruction set doesn't even know the concept. This is OK, since one of the main focusses of Java and the Java VM is for applications to focus on productivity, instead of low level features. Of course this is restrictive, it *has* to be.

An open source VM isnt much use

[jonwil]

Open source VMs already exist, what we need is for sun to open source the java libraries.

Re:An open source VM isnt much use

[RAMMS EIN]

``Open source VMs already exist''

Yes, but do they handle the full language that Sun's VM handles, and are they as fast?

Re:An open source VM isnt much use

[Anonymous Coward]

WTF? Of course they handle the "full language" of the VM, the Java VM is fairly clearly defined in an open spec. So is the class format and the language specification.

As for "as fast" that's sort of pointless, it's fairly hard to be slower than Java. But, yes, they're as fast (or not, as the case may be) as Sun's Java.

What is true is that most open source LIBRARIES fall far behind Sun's massively bloated "standard" library collection, which was the OP's original point anyway.

Re:An open source VM isnt much use

[TheRaven64]

Yes, but do they handle the full language that Sun's VM handles, and are they as fast?

The 'language' is quite small, it's just the virtual instruction set. Most of the Java platform is the runtime library, which is huge. There are a few non-Sun VMs, and some of them are very fast. The problem is implementing the libraries, and this is difficult because they are so big. The Classpath and Harmony projects are working towards this, but having Sun release theirs under a Free Software license would make this a lot easier.

Re:An open source VM isnt much use

[Anonymous Coward]

To bad they suck

Finally

[Ajehals]

FTA it looks like it really is, finally about to be reality (:)), Java under an OSI approved license. Not only that but within 60 days and all because of pressure from the community - I wonder where else that might work (drivers? - nah need a bigger market share...).

It looks like Sun Microsystems are starting to see the benefits of Open Source technology, first Open Office (Under the GPL no less) then Solaris and now Java, - I can only hope it catches on throughout the industry.

Just a couple of points - I know that Java isn't being released under the GPL, and that there are still some interesting debates going on about the CCDL and interoperability with the GPL (I wont even pretend to know the precise issues), but it is definitely a good thing. Since Sun Microsystems is primarily seen as a hardware company, and presumably isn't too worried about the revenue's it is losing from the software sales it could have had (I know this doesn't apply to Java but it could have to Open Office and did to Solaris) it does mean that nothing that they are doing can be readily applied to a Software company. So anybody suggesting that Microsoft et al should start Open Sourcing their code because it works for Sun Microsystems is probably a little off the mark.

Well anyway - Be a good day when it *actually* happens and his is very good news. I wonder if I should look at using Java...

PS: By the way (and slightly random) my spell checker in OO.org attempts to correct CCDL as CUDDLY and GNU-GPL as SNUGGLE, how sweet.

Re:Finally

[Anonymous Coward]

I think you give Sun a little more credit than they deserve. Sun is just panicking, not being enlightened.

Sun needs, desperately, to make their implementation of Java the defacto standard with Linux distributions. Their problem is Java is becoming open source right now. That's a comparison between a cleanroom, GPL implementation of Java and Sun's JDK 1.4. That's approximately 99% compatible aside from the swing api. And for a Tomcat or Jboss, that's all you need. Debian already distributes this in the main repository with SableVM. Red Hat favors GCJ.

Right now Sun is on the cusp of becoming irrelevant. They wanted so badly to prevent a fork of Java but it is already forked right under their noses. They need to dump a superior, complete, open source version of Java on the market RIGHT NOW and sweep support out from under these other projects and kill them with extreme prejudice. Lets face it, Solaris has no takers outside hardcore enterprise customers because we open sourced around them. In another year Sun's JDK will be just "that JDK that comes with Solaris" if they don't do something really soon. Then Java is forked and Sun has lost the standards battle with Microsoft in their eyes.

Personally, I think an independent Java Foundation needs to get spun off. That way IBM, Sun, Oracle, Red Hat, Intel, HP, and Apple can dump research money into Java without all the discomfort of working with a direct competitor. And finally, fast VM technology will enter the public domain and we can get rid of all this slow ass interpreted shit.

Re:Finally

[Anonymous Coward]

Hm, mine corrects them to "strangle" and "cockdiddle" respectively. You must not be using Microsoft Word.

Re:Finally

[lokedhs]

And I think you are giving the Open Source alternate implementations of Java a little more credit than they deserver.

The fact of the matter is that they for the most part suck. As you mention yourself, they are only now close to becoming 1.4 compatible. The problem, of course, is that 1.5 was a huge improvement over 1.4 and it came out over 3 years ago. 1.6 is in beta 2 and will be released soon.

You can spend a lot of time discussing performance comparisons between the different VM's like SableVM, but that's not really interesting. It doesn't really matter which "free" VM you use, you still don't have a modern class library available until Sun releases theirs. That is why an open sourced version of Java is interesting for these parties.

Personally, I think the Sun VM is fantastic, but giving the "free" alternatives the ability to use the same class library will only increase competition and that is good for everybody. Today, they are playing the catchup game, and that must be really boring, since no one that really matters actually use their product for anything important.

Re:Finally

[Anonymous Coward]

There are several problems with your argument. First of all, nobody uses Java 1.5 in production. Most professional IT shops are just starting to roll new projects over to Websphere 6.0 which is based on J2SE 1.4 and J2EE 1.4. J2EE 1.5 is not even out the door yet, much less of any interest to people who do real work with Java. Secondly, most library developers need to support at least Java 1.3, if not Java 1.2 for compatibility reasons. Very few require even Java 1.4 and most that do lamentably can't be used in many environments because of it. Embedded applications are even more restrictive. So not supporting Java 1.5 is not nearly as much of a liability as you make it out to be.

Third, there is no question the Sun VM is superior at the moment. But the key phrase in that sentence is "at the moment."

Five years ago Solaris wiped the floor with Linux. Today I don't see people flocking to Solaris despite its handful of technological perks. Linux is just too damn handy. There are realtime versions, secure versions, embedded versions. All based on the same kernel, all free and open, and they all just work.

In 5 years the difference between Sun's VM and the open JVMs will be negligible if not in the open VM's favor. If Sun waits any longer they will pass the point where they can kill off competing projects so easily. The open VMs will have been adapted to fit on tiny microcontrollers, had realtime patches applied to them, and run on more platforms than Sun's JVM could hope to. To make a relevant comparison, you can talk about how ICC optimizes this and that in such an elegant way that it's 100x faster than GCC for this specific use. But the point is everyone in the open source community uses GCC, all the projects were built up on GCC, hardly anything compiles correctly with ICC, and GCC just works. And if you've been following the open source movement the same thing is happening at Debian and RedHat. They are not targeting Sun's Java 1.5. They are targeting SableVM, GCJ, and GNU Classpath. This scares the bejeezus out of Sun.

Re:Finally

[lokedhs]

First of all, nobody uses Java 1.5 in production.

Nobody? Without even mentioning the projects I have had direct influence in, and were in production years ago on 1.5, I'll just present you with one link as a counter-argument: Migration to Java 5 at walmart.com.

Most professional IT shops are just starting to roll new projects over to Websphere 6.0 which is based on J2SE 1.4 and J2EE 1.4. J2EE 1.5 is not even out the door yet, much less of any interest to people who do real work with Java.

Java EE is not Java SE. Don't take me wrong, I'm a huge fan of Java EE and I want JEE5 to make it as soon as possible. However, you can use 1.5 with previous versions of Java EE, and even if you don't even use many of the new language features or libraries, some 3'rd party library you use may very well be.

Third, there is no question the Sun VM is superior at the moment. But the key phrase in that sentence is "at the moment."

I believe that was my entire point of the previous post. The Sun VM is superiour at the moment. The main reason it is is because the others have to play a catchup game that they cannot win. Sun opening the license means that the alternative implementations may get a boost, and be able to actually implement the modern versions of Java instead of being stuck in the dark ages.

Five years ago Solaris wiped the floor with Linux. Today I don't see people flocking to Solaris despite its handful of technological perks. Linux is just too damn handy.

Solaris still wipes the floor with Linux, but quality has never been the main reason people choose a technology. Convenience and lazyness are often much more important. I myself prefer to run Linux on a desktop even thugh all my servers run Solaris. Why? It's certainly not because Linux is a technologically better platform, it's because it's much more conventient. All the desktop hardware drivers are there and all the end user applications just work.

There are realtime versions, secure versions, embedded versions. All based on the same kernel, all free and open, and they all just work. There is not really a huge advantage to run the same kernel everywhere. Especially not when the API's are very similar as is the case of Linux and Solaris.

On the Java side the VM is even less important since you don't even need to recompile your binaries. The argument that, say, SableVM would take over on the server just because they have an embedded version just doesn't make any sense. There are no visible differences between two competing, certified, versions of Java. However, if SableVM manages to come out with a certificed, compatible version that wipes the floor with the Sun VM on the server, then why wouldn't people use it? However, right now they can't because they're stuck trying to catch up with Sun who are always 2 versions ahead.

To make a relevant comparison, you can talk about how ICC optimizes this and that in such an elegant way that it's 100x faster than GCC for this specific use.

It doesn't. It's a few percent faster. Not usually niceable unless you hit some very specific edge cases. GCC is quite decent on Intel hardware. Thies goes back to the onvenience argument I made earlier. Technological advantages are usually not the major deciding factor.

And if you've been following the open source movement the same thing is happening at Debian and RedHat. They are not targeting Sun's Java 1.5. They are targeting SableVM, GCJ, and GNU Classpath.

Most Java projects doesn't care one bit what the Linux distributions target. They would never deploy on anything but the Sun VM anyway.

Re:Finally

[Anonymous Coward]

Is that why Apache has such a disinterest in an open source JVM that they started their own Project Harmony? Which within a year mostly implements J2SE 1.4 and 1.5. And they are getting block code donations from IBM and Intel.

Ohhh RIGHT. Nobody uses Apache projects for Java. And IBM? I've never used their stuff! What do they make with Java?

Hmm. Now what projects even work with GCJ? Eclipse. Is that like TextPad? Open Office. Is that what includes Word Perfect now? Face it. Soon GCJ will fully support SWT and Swing and open source users will have no reason to load the Sun JVM. From there it's just a performance game.

Firefox : Iceweasel :: Sun Java : ???

[Gracenotes]

The dichotomy that exists between Microsoft Java (which is pretty bad) and Sun Java is, if not jarring, quite irritating. Thankfully, Sun Java is the norm. But if Sun Java is released under the GPL, I expect to see several more versions of Java, most of them incompatible with each other, coming out soon. Iceweasel, anyone?

Re:Firefox : Iceweasel :: Sun Java : ???

[Ajehals]

Good point,

And wasnt that why Sun Microsystems were *not* going to Open Java? Im sure I remember reading that they wanted to maintain control of the development of the language and its implementation, although that was a long while ago.

I wouldn't though compare this to the Debian - Firefox - Iceweasel scenario though, as Debian are not Forking Firefox, developing it independently and making it less compatible, but simply working around some (legitimate) issues that Debian have with Mozilla. (and Mozilla has a perfectly sensible stance on the issue too - Im a Debian user but I don't think you need to take sides over that particular issue - Both groups are aiming at the same goal, but with slightly different ideas of how to get there.)

Re:Firefox : Iceweasel :: Sun Java : ???

[Shados]

Yeah, that would be pretty bad. This is something that has always been bothering me, but I just thought about something while reading your post.

While not 100% true in all cases, the beauty of java isn't really in the base JVM, its in J2EE. At least, it is what pushes it in the corporate space, where the money is. With that in mind, a specific J2EE implementation usualy has a couple of "supported" JVMs (sometimes only one even). So I suspect even these alternate JVMs, at least the serious ones (which would want to work with J2EE, or else be forgotten), will stay in line (read: compatible) with the commercial J2EE implementations, or die. So while we WILL see a bunch of weirdo useless JVM/Java implementations (I realise both aren't the same thing, but the logic still stands), there should be a couple that stay at the top, and we'll just use those.

Re:Firefox : Iceweasel :: Sun Java : ???

[DragonWriter]

But if Sun Java is released under the GPL, I expect to see several more versions of Java, most of them incompatible with each other, coming out soon.

So? There already are several more versions of Java. What keeps the ones that succeed largely compatible isn't licensing (as the non-Sun, non-Microsoft ones are reverse-engineered, not licensed) but the fact that there is no interest in incompatible "Java". Releasing Sun's implementation under the GPL (or the CCDL, or, heck, into the public domain) isn't going to change that.

Re:Firefox : Iceweasel :: Sun Java : ???

[Samah]

> The dichotomy that exists between Microsoft Java (which is pretty bad) and Sun Java is, if not jarring, quite irritating. Thankfully, Sun Java is the norm. But if Sun Java is released under the GPL, I expect to see several more versions of Java, most of them incompatible with each other, coming out soon. Iceweasel, anyone?

Jarring?
....
:)

Re:Firefox : Iceweasel :: Sun Java : ???

[kevin_conaway]

The dichotomy that exists between Microsoft Java (which is pretty bad) and Sun Java is, if not jarring, quite irritating. Thankfully, Sun Java is the norm. But if Sun Java is released under the GPL, I expect to see several more versions of Java, most of them incompatible with each other, coming out soon. Iceweasel, anyone?

I see what you're doing there..

Re:Firefox : Iceweasel :: Sun Java : ???

[geekoid]

"Iceweasel, anyone?"
No thanks, my pants are already full.

Re:Firefox : Iceweasel :: Sun Java : ???

[TheRaven64]

Actually, the FireFox IceWeasel thing is an excellent comparison. Sun might open the Java code, but they would retain the Java trademark. If you wanted to fork Java, you couldn't call the result Java. Any Java application would work on any Java(TM) VM, but it might not work on a KenyanPeaberry VM.

Re:Firefox : Iceweasel :: Sun Java : ???

[adrianmonk]

But if Sun Java is released under the GPL, I expect to see several more versions of Java, most of them incompatible with each other, coming out soon. Iceweasel, anyone?

This is why open computing is not based only on the available of open source. Another key element of open computing is open standards. Java has open standards; you can go download the Java Language Specification and check if any given implementation conforms to it or not. You can also go download the Java Virtual Machine Specification and see if some compiler is producing correct bytecode or if some JVM is running the bytecode correctly.

Yes, it's possible someone may fork an implementation of one or the other (the compiler or the JVM) and make incompatible changes. That would be fairly silly, but that doesn't mean it won't happen. One expects that Sun will allow them to have the source code but will not grant them the right to say it is a conforming implementation of Java if it's not. I assume that is what you're getting at with the comparison to Iceweasel.

The thing is, this has always been possible. There are open source Java compilers and open source JVMs as well. The thing Sun is doing is making it easier, because they are (apparently) open sourcing their JVM, which creates more opportunity and more interest in doing something with that particular implementation.

Re:Firefox : Iceweasel :: Sun Java : ???

[VGPowerlord]

In case you forgot, Sun sued Microsoft to stop them from diverging (further) from the standard.

The end result was Microsoft creating .NET to compete with Java.

Re:Firefox : Iceweasel :: Sun Java : ???

[VGPowerlord]

It's funny that you should say that. From what I heard, EJB3 (part of J2EE 5) uses annotations extensively. Annotations are a core J2SE 5 feature.

Re:Firefox : Iceweasel :: Sun Java : ???

[Anonymous Coward]

Yes, the war of different terms really jars the ear.

bleh, that probably wasn't worth typing.

Re:Firefox : Iceweasel :: Sun Java : ???

[Ferzelic]

But if Sun Java is released under the GPL, I expect to see several more versions of Java, most of them incompatible with each other, coming out soon.

You mean, as opposed to the situation we have now, where the non-Sun implementations are 100% fully compatible across the board?
(Kaffe, Classpath, GCJ, Japhar etc)
One reason none of them use 'Java' in their name is because they have not demonstrated full compatibility.

The situation will be no worse than it is today. With an open source Java, other implementations can take the Sun source, and either maintain full compatibility & pass the test suite to use the Java trademark, or break with compatibility and work under a different name. As it stands today, 3rd parties need to implement the spec from scratch -- and either pass the test suite to use the Java trademark, or break with compatibility and work under a different name. (As no totally independent code has at this stage fully passed all tests, there are no 3rd party 'Java' implementations; only software that is mostly Java-compatible.)

By working from an independent code base, incompatibilities are actually far more likely across implementations, than if there is a common core of source they can share.

Iceweasel, anyone?

Yes -- exactly like IceWeasel. If you make changes to the codebase that are not approved by the trademark controlling body, you will have to use a different name. The brand is used as an indicator of compatibility.
This is actually kind of opposite to what you fear though; Firefox and IceWeasel will remain very much compatible, despite having different names.
What would be bad is if radically altered products were allowed to share the same name... that's where the worst problems would occur.

Been there, done that...

[Anonymous Coward]

Blackdown provides a 64-bit plugin. It has even more stablity problems with almost no human noticable performance benefits. There are some advantages to using a 64-bit JRE such as SSL/TLS in Tomcat (and other servers side applications) but for 99% of client side webapps that just does not seem to be the case. Also, using a 64-bit browser also means no Adobe/Macromedia Flash Player plugin for you! I know some YouTube junkies that "need" Flash more than they need Java.

umm yeah ... who cares

[darkchubs]

the terms of Suns open initiate are so strict that Im not really all that excited.. you see how great it was for openSolaris.. it was a touted as a Linux killer??? well , in short .. nothing is gong to change..

Re:umm yeah ... who cares

[petermgreen]

there is a big difference

solaris was never a big player on anything other than (expensive) sun hardware and even there linux was creeping in.

sun java is the primary implementation of java. That is it is what everyone writes there code to work with and what you expect to find if you purchase java hosting.

as to the license terms iirc the CDDL is a mozilla like license, incompatible with the GPL (but then so is nearly every copyleft license other than the GPL itself). Opensourcing the real thing will remove most of the motivation to develop clones (afaict the main motivation for developing the clones has been to get java into linux distros etc).

Re:umm yeah ... who cares

[TheRaven64]

The CDDL, under which OpenSolaris is licensed, is approved by the OSI, and the FSF calls it a Free Software license. The 'restrictions' are things like patent defence clauses. Will OpenSolaris kill Linux? I don't know, but for a new installation I would definitely chose it; there are a number of features where OpenSolaris wins over Linux (ZFS by itself would be a major winner), which are not likely to be ported to Linux since the CDDL is not GPL compatible.

Re:umm yeah ... who cares

[McBofh]

Solaris and OpenSolaris were never meant to be "linux killers" - that's something people who don't understand enterprises fail to realise. Enterprises don't want single-source IT suppliers, they want multiple sources. That's *exactly* why the mob I'm working for right now has HPUX and Solaris and MS-Windows.

And anyway, there's much more to be gained for all of us if linux and (Open)Solaris use each other as sources of inspiration. Ever heard the term "co-opetition" ? That's what the industry needs. Monopolies are almost always bad for customers, and Sun fully realises that.

Re:Java Q

[ettlz]

load times of an app are Tight, like cunt of nun?

Whoa, whoa, whoa, back up — just how the fuck do you know that?!

You the Vatican's official gynaecologist or something?

And HW accelerator licencing ...? ARM, AVR32, etc

[Big Jojo]

Still wondering if this means they'll be opening up specs on how the ARM Java acceleration works ... it would be nice to have some of those free JVMs able to use that to speed up their bytecode interpretation.

For those of you who don't know about this, most modern ARM CPUs -- like the ARM-926ejs as found in the Nokia 770 and many cell phones -- include three processor modes: (1) pure 32bit ARM instructions, (2) a 16-bit compressed version of ARM instructions called "Thumb", widely used in microcontrollers, (3) an 8-bit Java bytecode interpreter. The first two have public documentation. But ARM won't give docs to the last out, because Sun won't let them do that; you need a separate licence from Sun to get those documents. So it's fully within Sun's power to open up some widely available Linux-savvy hardware to run Java a lot better ...

There's another CPU that's in the same kind of boat, the new AVR32 from Atmel. You may have noticed that Linux 2.6.19-rc includes initial support for that architecture. AVR32 CPUs have analogues of (1) and (3) above ... but again, Atmel won't give docs to the Java acceleration out, because Sun won't let them do that. (And for background info: yes AVR32 is very new, likely its audience today is almost all developers, only one model of chip available so far.)

So how about it, Sun ... are you really going to open Java up??

Think outside the box

[Asztal_]

We need slower slugs.

Re:Think outside the box

[oldwarrior]

We have to replace these outdated notions of performance. Slower slugs are actually BETTER for our users. See Ruby on Rails for details.

Microsoft Java is pretty bad... but Sun's blows

[Anonymous Coward]

The Sun Java virtual machines jumped the shark the same month they won the lawsuit against Microsoft.
Their latest versions are bloated, phoning-home pieces of crap that suck ass almost as bad as RealPlayer...
and, like RealPlayer, in-the-know independent system builders go to OldVersion.com to obtain a replacement.

We build or rebuild several systems a month with Microsoft's VM and no Sun VM. The machines run better, and have no problem handling the vast majority of java applets.

If you're writing code that demands a specific brand or version of Java virtual machine, perhaps you should learn to write better code instead.

I'll believe it when I see it.

[Ungrounded Lightning]

Sun has a multi-decade track record of talking about opening things, but not really doing it.

I'll belive this is really "open" when (if) I see it and it's really open.

And if so it will be a first for Sun.

Re:I'll believe it when I see it.

[Anonymous Coward]

Would this include OpenSolaris and OpenOffice?

Which decade are you referring to?

Re:I'll believe it when I see it.

[TheRaven64]

You're so right! They never open sourced NFS. They never open sourced OpenOffice after buying it from Star Division. They certainly never opened any of Solaris or J2ME.

Re:I'll believe it when I see it.

[kaffiene]

Fucking moron. Sun have OS'd more software than anyone else I can think of.

OpenOffice,
OpenSolaris,
NFS,
Netbeans,
GlassFish
etc etc

Sun also contributes to Gnome, X.org, PostGreSQL, Mozilla and many other projects.

Get a fucking clue and stop spreading the same old FUD.

Re:I'll believe it when I see it.

[Ungrounded Lightning]

Would this include OpenSolaris and OpenOffice?

I stand corrected.

You're right: At the very least about OpenOffice,
and I should have remembered that they DID release
the code (even though they kept the "Star" version,
which my employer runs on many of its machines,
proprietary.)

The first time they "opened" Solaris they didn't
really - one of those non-free licenses - and I
threw in the towel on paying attention to them
when I migrated from last personal Sun instalation
to Linux.

Which decade are you referring to?

'80s and '90s. The above-mentioned migration was near
the end of 1999. (No point in dealing with the Y2K bug
on more than one platform.)

I'll be happy if Sun is truly opening things,
and sincerely apologize if I have wronged them.

But for me it's too little too late. I spent too many
years crippled by their closed / semi-opened software
and hardware to go back. Linux and BSD each suit my
needs and both are truly open (in slightly different ways).

Microsoft Java VM

[Veilrap]

Ummm, didn't Sun sue Microsoft because they wanted to keep full control over java? Now that their opening it up doesn't this give microsoft the right to produce/release their own virtual machine again?

Re:Microsoft Java VM

[DragonWriter]

Ummm, didn't Sun sue Microsoft because they wanted to keep full control over java?

No, Sun sued Microsoft because Microsoft was violating the terms of their licensing agreement with Sun. (Now, Sun might have drafted the terms of that licensing agreement because, at the time, it wanted to maintain full control of Java, but that's a different question altogether.)

Re:Microsoft Java VM

[Wesley Felter]

Microsoft already created their own pseudo-Java (.NET), so now there's nothing worse they could do to Java. Likewise, there are already N different incompatible open source JVMs, so that situation can't get any worse either. Having nothing to lose, Sun can now give up some control.

Re:Microsoft Java VM

[TheNetAvenger]

Microsoft already created their own pseudo-Java (.NET), so now there's nothing worse they could do to Java. Likewise, there are already N different incompatible open source JVMs, so that situation can't get any worse either. Having nothing to lose, Sun can now give up some control.

1) .NET is a far distance from JAVA, at least .NET can pull credible performance out of its engine.

2) The original post is quite right, SUN (even though it was a license dispute) argued specifically against JAVA being NOT under their control or have ANYTHING added to it that they didn't want. Opening of JAVA would do exactly what they argued was bad about MS's JAVA implementations.

3) You are correct, MS is no longer an issue, but on the same front, JAVA is no longer an issue as well. JAVA development is at an all time low in the industry for serious development where you see .NET used on everything from Web Servers to even even performance areas like DirectX9 - again something JAVA just can't reach. And now you have the graphic and communication libraries of Vista added to .NET making it 3.0, allowing for easily coded 3D application interfaces, new communication concepts and even possible wider cross platform support with WPF/E.

Re:Microsoft Java VM

[freedom_india]

1) .NET is a far distance from JAVA, at least .NET can pull credible performance out of its engine.

Exxcuusseee me??? Since when did .Net performance in Enterprise Computing exceed that of Java?

Have you worked for an enterprise (like Bank Am, Capital One), where millions of transactions happen every day? Have you ever tried out servers like WAS 5.1.2, or WLI 8.1 SP3?

To put it mildly, Java beats the socks and b*lls off .net in enterprise computing which involves making your server running with 5 nine's reliability. I doubt whether .net would meet 3 nine's satisfactorily without screwing up somewhere

Yes, i agree their VM stuff is very easy to code for. But deployment in production? MSFT has a loooong way to go.

Re:Microsoft Java VM

[feijai]

.NET is a far distance from JAVA, at least .NET can pull credible performance out of its engine.

Care to back up that ridiculous implication (that .NET is much more efficient than Java) with even a modicum of evidence?

3) You are correct, MS is no longer an issue, but on the same front, JAVA is no longer an issue as well. JAVA development is at an all time low in the industry for serious development where you see .NET used on everything from Web Servers to even even performance areas like DirectX9 - again something JAVA just can't reach.

Oh, man, that was funny. Thanks, I needed some humor today.

Oh, wait this was serious? I guess I should expect as much from someone who thinks "JAVA" is an acronym.

Re:Microsoft Java VM

[TheNetAvenger]

Care to back up that ridiculous implication (that .NET is much more efficient than Java) with even a modicum of evidence?

How about DirectX 9.0 uses .NET in places, and it is a PERFORMANCE graphics library? Port part of OpenGL to JAVA and see how well that works for you...

I guess I should expect as much from someone who thinks "JAVA" is an acronym.

Almost as funny as someone that thinks it is a viable development enviroment. Stick with the drink, it at least moves faster than molasses...

Re:Microsoft Java VM

[TheNetAvenger]

To put it mildly, Java beats the socks and b*lls off .net in enterprise computing which involves making your server running with 5 nine's reliability. I doubt whether .net would meet 3 nine's satisfactorily without screwing up somewhere

Deployments in this scale are more common than you seem to realize. Just because you may not be working in environments with large scale MS .NET, don't assume they don't exist and don't assume that just because the solutions you are being fed based on Java are the best for reliability or performance.

You are trying to paint a pretty picture of Java, which is fine, but the context isn't working in this example.

We could spend 100 pages of posts on just the 'necessary' integration software for the Java examples you cite. These are tools to not only integrate messes, but also work around massive flaws.

Java works in the deployments you are referencing because of the legacy integration that is necessary, not because it is the MOST reliable.

I can give you examples of companies still dragging COBOL along, but this doesn't mean it is reliable, fast, nor even the enterprised model, it is still used because it is based on data systems 25 years old.

Re:Microsoft Java VM

[feijai]

How about DirectX 9.0 uses .NET in places, and it is a PERFORMANCE graphics library? Port part of OpenGL to JAVA and see how well that works for you...

You mean like jogl? Seriously, do you know anything about this language?

Re:Microsoft Java VM

[TheNetAvenger]

You mean like jogl? Seriously, do you know anything about this language?

Wow a Java API interface for OpenGL. There is a difference between APIs for Java to use OpenGL and actually writing OpenGL in Java.

Do you even know what you are talking about? Guess not...

In reference to your link:
JOGL provides full access to the APIs in the OpenGL 2.0 specification as well as nearly all vendor extensions, and integrates with the AWT and Swing widget sets.

This is NOT OpenGL being written in Java.

Re:Microsoft Java VM

[feijai]

Mmmm. And you've fallen for the notion that Microsoft is actually writing DirectX's core APIs *in* .NET, have you? Bull Honky. .NET is getting an API to DirectX and certain high-level, non-performance-related elements of DirectX may be written in .NET libraries for .NET programs only. There is no relevant difference between this and jogl. You're a twit, and I'm done with you. Go read a book on computer science.

Re:Microsoft Java VM

[TheNetAvenger]

Mmmm. And you've fallen for the notion that Microsoft is actually writing DirectX's core APIs *in* .NET, have you? Bull Honky. .NET is getting an API to DirectX and certain high-level, non-performance-related elements of DirectX may be written in .NET libraries for .NET programs only. There is no relevant difference between this and jogl. You're a twit, and I'm done with you. Go read a book on computer science.


Wow, write a few lines and all the crazy people come out to play.

Direct9.0c moved portions of the code base into managed .NET code. Go do a bit of research on this before you just declare yourself God and strike down anything you don't understand.

CDDL? I don't think so...

[hacker]

Open has very different terms, and CDDL is not one of them, period. I'm not saying it has to be GPL or BSD licensed, but CDDL is simply an unworkable license, since it is incompatible with the majority of Open Source licenses out there.

Opening Java might sound all well and good, but not if you can't do anything at all with it, without violating the license terms.

Thanks, but no.

Re:CDDL? I don't think so...

[Alphager]

I'm a FSF-fan and think the GPL is the way to go, but the CDDL is an OSI approved license. You _can_ modify the code and distribute it. You _can_ do all sorts of stuff with it.

Re:CDDL? I don't think so...

[Anonymous Coward]

Sorry, having read all the licenses, you're quite wrong - the GPL is incompatible with CDDL, it's Stallman's restrictions that prevent intermingling. The CDDL is perfectly supportive of any other file (in that the license is non-viral). CDDL is compatible with all other OSI approved licenses (and is, as well, OSI approved). You should read and understand the licenses before you go spewing ignorance, Floyd.

Re:CDDL? I don't think so...

[TheRaven64]

Open has very different terms, and CDDL is not one of them, period.

Interesting. The Open Source Initiative disagree with you, and the Free Software Foundation describe it as a GPL-Incompatible, Free Software License. Sounds pretty open to me. Oh, and I actually have read the license; I suggest you do to.

Re:CDDL? I don't think so...

[hacker]

You might want to read some more before you make a blanket generalization like this.

This earlier Slashdot thread also has lots of accurate commentary and links as well. I suggest reading those also.

In short, the CDDL is great, as long as you don't want to:
a.) Incorporate it with anything covered by the GPL or the LGPL (so most of Linux is out),
b.) Distribute it to the public
c.) Sell anything built with CDDL code commercially

Doesn't sound very useful to me (and several thousand other developers who agree with me), and in fact, with OSI's discussions of changes to the model, they may end up deprecating the CDDL anyway.

The OSI has explicitly stated that one of its new policy goals "will be to promote unrestricted reusability of code." The CDDL is incompatible with that strategy. (More on that over here).

Nun cunt.

[Anonymous Coward]

Now that you mention it, that sounds hot as hell. Maybe I'll go nail me one...

Re:And HW accelerator licencing ...? ARM, AVR32, e

[audi100quattro]

Let's not forget that the Java on cellphones, J2ME, is a small subset of J2SE or J2EE. The interpreter may not speed up too much J2SE code. J2ME API's (maybe VM?) seem to be open source already based on a quick google search: http://www.sun.com/software/communitysource/j2me/ atleast the MIDP/CLDC/CDC parts.

It would be interesting to know exactly how the chipmakers went about implementing the interpreters in hardware and/or firmware.

How is this ever going to end?

[Anonymous Coward]

Is this going to end up like Al Capone's vault on Geraldo?

So in other words

[Silent sound]

So in other words, they're not open sourcing Java.

Re:So in other words

[jonwil]

Acording to http://www.opensource.org/licenses/ the SUN CDDL (which is what they used for OpenSolaris) is an open source license. It is not a Free Software licence and is incompatible with the GNU GPL but it is still an open source license.

Re:So in other words

[Anonymous Coward]

Actually, the CDDL is a Free Software license, albeit a GPL-incompatible one, according to the FSF. See http://www.fsf.org/licensing/licenses/index_html.

Re:So in other words

[hritcu]

Apache 2.0 and many other perfectly valid free software licenses are GPL incompatible. Maybe things will change with GPL v3.

Re:So in other words

[ajs318]

What exactly is the difference between Open Source and Free Software? I mean, apart from the Free Software movement being a bunch of smelly communist carrot-munching hippies looking for ideological purity and the Open Source movement being a bunch of tight-fisted grasping breadheads looking for a free ride on the hard work of others.

Is it possible to have Free Software that isn't also Open Source? Is it possible to have Open Source software that isn't also Free software? Or is the distinction between the labels more to do with what each camp thinks of the other camp? Is the in-fighting reaching the point where it becomes counter-productive?

Re:So in other words

[Anonymous Coward]

Mmm, yummy trollicious bait.

Answers to your "questions" here: http://www.gnu.org/philosophy/free-sw.html

Re:So in other words

[ajs318]

That really doesn't explain much; only that there are two different definitions (Richard Stallman's Four Freedoms, and Bruce Perens' guidelines).

Have you an example of a licence which meets one definition but not the other?

Re:So in other words

[squiggleslash]

A somewhat controvertial example might be the original versions of the APSL (Apple Public Source License) under which early versions of open-source Darwin were released.

The FSF considered it non-free for a variety of reasons, not least Apple's ability to revoke it at any time. It was heralded as "Open Source" by ESR, then head of the Open Source Initiative. Of course, many people argued it wasn't, and it was part of the reason for the schism which ended up with Bruce Perens quitting the OSI, IIRC.

Re:So in other words

[thephotoman]

Open Source and Free Software aren't entirely the same thing.

For example: Java is Open Source, in that it is produced from a public collaboration, but is not Free Software, as I'm not allowed to make changes and/or redistribute the source myself. Another example would be anything released under the Apple Public Source License v.1.0. Version 2 of that license is both Open Source and Free Software.

On the other side of the coin, GNU Ada was formerly developed under a model much like most proprietary software, but at the same time, nobody beyond the GNU project's blessed people had access to the CVS/Arch/whatever archives, nor was it particularly easy for third parties to submit patches back to the project.

Re:And HW accelerator licencing ...? ARM, AVR32, e

[Anonymous Coward]

an 8-bit Java bytecode interpreter... But ARM won't give docs to the last out, because Sun won't let them do that

http://www.arm.com/products/esd/jazelle_architectu re.html

Put the processor in "Java bytecode" state, and it executes 8-bit Java bytecode directly. It's a third instruction set for the core, in addition to the ARM and Thumb instruction sets.

ARM doesn't document the Java bytecode. They refer you to Sun, which seems appropriate since that spec is proprietary to Sun.

Pick a processor core with "J" for "Jazelle" in the name, and read the Architecture Reference Manual.

"You can switch the operating state of the ARM7EJ-S core between:
        - { Thumb mode deleted }
        - ARM state and Jazelle state using the BXJ instruction"

http://www.arm.com/pdfs/DDI0214B_7ejs_r1_trm.pdf

"BXJ" stands for Branch and Exchange to Jazelle. It works like the other ARM branch instructions. If you have some bytecode at address X, then load X into r0 and "bxj r0". The processor starts executing the bytecode at that address.

What else do you need to know?

(Yes, the manual does go on to discuss exceptions that take you back out of Jazelle mode, what happens when the processor hits emulated/extended byte codes, and so on. You want to implement JIT to native ARM code, you can do that, too -- but that's your software problem.)

No big conspiracies here, it seems. Took me three searches on the ARM web site to find the info.

In other news...

[Schraegstrichpunkt]

... the new Amiga is just around the corner!

I'll believe it when it happens.

Re:In other news...

[HishamMuhammad]

Crap, Amiga has been gone for so long people don't even relate to these jokes anymore to mod them funny....

It's essential that Java not fragment

[presidenteloco]

A wise zen monk went into a fast-food joint and said "Make me one with everything."

An even wiser zen monk didn't go into a fast-food joint, and said
"Make me one OF everything."

One standard version of core Java things like the language definition, bytecode definition,
and the annointed standard libraries is absolutely ESSENTIAL to Java's continued success.

Because "one of everything" means that a java app and library code-sharing culture and a
shared and reusable expertise can flourish. Fragmentation of the core standards will lead
to disintegration of the core value proposition of Java.

I hope that this issue can be dealt with as Java is opened.

Perhaps by trademark protection means? Break (fork) the standard if you want, but if you do
you can't call it Java.

Or perhaps just by a consensus-agreed committee approval structure like the java community
process.

Can you imagine if everyone were free to fork the XML standard and still call it XML.
Sheer pointless chaos.

Java forked in its core standards and libraries is the same.

Re:It's essential that Java not fragment

[shish]

Java is *already* fragmented (AFAIK; Sun, MS, IBM, GNU, Apache, and a couple of others all have their own implementations; then there are java subset forks like sable and jikes) -- several of these were created precisely because java was proprietary. AFAICS, having it be truly open sourced should stop any more implementations being needed, and maybe it could get some of the existing open source versions to merge all their best bits into one~

Re:It's essential that Java not fragment

[jonaskoelker]

> Can you imagine if everyone were free to fork the XML standard and still call it XML.
> Sheer pointless chaos.

Even worse, what if people were free to fork javascript? Or HTML? :)

I don't like it, but hope for a GCJ killer

[Anonymous Coward]

The problem with open source today as I see it is seperation. Many people share many different ideas and believes and if there isn't an entity which can lead it all into good paths you're in for chaos. Sometimes this doesn't have to be bad perse but it can be annoying.

As you can see today with many package maintainers who's only link with the software they're maintaining is that they like it. Only 2 weeks ago did I try to utilize FreeBSD and its ports. I already installed MySQL 4.x and then wanted dspam. No go.. It demanded I used MySQL 5.x. A perfect example IMO, the package maintainer asks...

And that is why I don't like the idea of Java going open source. Still, despite all that I truly hope it might turn out to be a GCJ killer. Why? If there is one thing turning off Linux people from Java it has got to be gcj.. How frustrating can it be when you're trying example code and only come to the conclusion that it simply doesn't work? You typed everything as it should, you studied the code yourself but yet it does. not. work. Well, enter gcj hell. If you're going over the Java tutorials you'll be sure to run into some beginner examples which will not run when using gcj.

In fact, many of the usenet and irc groups I'm on start asking people if they're using gcj when experiencing problems on Linux. If so then the advice is: ditch that POS and get the JVM from Sun. Strangely enough this fixes the problem in most of the cases. So yes, I don't like the idea of Java going open source but I'd be very pleased if this stopped the gcj idiocy and got distributions to ship with the official and working Java Virtual Machine. The one from Sun ofcourse...

IBM Trolls

[javacowboy]

I can't believe how many IBM trolls are in this thread (and Slashdot as a whole) decrying Sun's lack of a track record in open sourcing their stuff.

Have they ever heard of NFS? OpenOffice? OpenSolaris?

Is there something wrong with the CDDL that's not wrong with the Mozilla license? From what I understand, the CDDL is similar to the Mozilla license but simpler. I invite every single one of those armchair critics to stop using Firefox if they're so adamant.

Unlike IBM (with the exception of Eclipse), Sun actually *open sources* stuff. I invite those IBM trolls to push their corporate master to open source WebSphere, DB2, Rational Rose, or Lotus Notes.

Re:IBM Trolls

[EvanED]

Is there something wrong with the CDDL that's not wrong with the Mozilla license? From what I understand, the CDDL is similar to the Mozilla license but simpler. I invite every single one of those armchair critics to stop using Firefox if they're so adamant

In all fairness, FF is dual-licensed under the GPL.

Re:IBM Trolls

[Vulcann]

In all fairness, FF is dual-licensed under the GPL.

Would it have made any difference to uptake if it wasn't ?

I would have to agree with the original poster on this. IBM has a habit of badmouthing everything about Sun while not doing a shitworth of anything unless it directly benefits itself. Open sourcing Eclipse was a good move but it is TINY compared to open sourcing Solaris 10 for instance. Most of the patents they release to "the community" are much less philanthropic measures - they are just aimed to make them look warm and fuzzy, and "open". Many of those patents probably don't make a whit of a difference to the free software community either way.

Even after OpenSolaris came out, IBM and RedHat jeered it for not being "open". WTF! Lets see them open source AIX .. then we'll talk.

Re:IBM Trolls

[EvanED]

Would it have made any difference to uptake if it wasn't ?

I dunno. Not directly anyway. Maybe if it affected the quality not being able to link in GPL code, or encouraging developers... but I think that only the very tinyiest minority of users would distinguish not only between Free/nonFree, but GPL compatible and not.

Anyway, I don't know enough to make any comment on the original post's main thrust, but saying that "if you're so stuck on having GPL compliance than stop using Firefox because it's not released ONLY under the GPL" is just silly.

Re:IBM Trolls

[hritcu]

You are right about IBM trolling here. However, IBM is a well known financial supporter of the Apache foundation and was the first big player pushing Linux. Let's not undermine their contribution to free software/open source.

Re:IBM Trolls

[GigsVT]

Would it have made any difference to uptake if it wasn't ?

Yes, I believe so. I know I was using Opera, and primarily switched to Firefox due to license. Of course most end users won't care, but one early user like me plants the seeds for many other users. One example is that our company web site is only tested in Firefox now, and validated by the w3c. If anyone has a problem with it, I make them download Firefox.

Isn't the garbage collector supposed to minimize.

[clayasaurus]

Isn't the garbage collector supposed to minimize memory leaks? At least C++ has an excuse.

Holy Smokes!

[Anonymous Coward]

"Or Java that utilizes the 64 bit arch as well as take advantage of dual core processing and hyperthreading."

That would be AWESOME! It might actually be as fast as 32-bit single threaded C!

I gotta say I was expecting this

[adamkennedy]

About 2 months ago, a Sun programmer dropped into #perl to ask some questions.

They were cleaning up some bitrot for a program that had only been used once before.

The program was written to check the OpenOffice source code for intellectual property owned by other companies, so that they could release it cleanly.

The program written for OpenOffice had been pulled out of the archives and was being overhauled for the purpose of checking the source code for Java for similar intellectual property issues, so they could release it cleanly.

So yep, it's almost certainly going to happen. They are certainly doing the work internally to make it happen.

Re:Isn't the garbage collector supposed to minimiz

[lnjasdpppun]

Minimize, yes. Eliminate totally, no.

It's still easy to have memory 'leaks' in a language with a GC.

Extensive libraries

[tepples]

you can go download the Java Language Specification and check if any given implementation conforms to it or not. You can also go download the Java Virtual Machine Specification and see if some compiler is producing correct bytecode or if some JVM is running the bytecode correctly.

But how big is the Java Library Specification? How can one be sure that an implementation of all of java.* and javax.* is 1. possible within human life span and 2. correct?

The libraries are horrid.

[Anonymous Coward]

The Java standard libraries are rather horrid.

What we often find is that they fuck up royally the first time they attempt to add some functionality. Soon enough the very obvious problems with their implementation are seen, and then they're forced to try again.

This happened with collection classes. First there were classes like Vector and Hashtable. Soon enough, they ended up being replaced by ArrayList, LinkedList, HashMap, and a host of other classes and interfaces that make up the Java Collections Framework. But the new JCF classes aren't threadsafe, which often causes problems. There are remedies, but they often make things even worse.

Of course, then there was the AWT to Swing transition. Both are horrible. AWT is lacking in many respects, and was not suitable for serious cross-platform applications. Swing, on the other hand, has absolutely terrible performance. What should have been done was a mixed native/virtual widget technique, as done by IBM's SWT.

There are other examples. But the bottom line is that the Java libraries have become a real pile of shit. You have deprecated junk that's in there for backwards compatibility. You have multiple poorly-designed classes for doing the same thing. It's just a shitty situation.

What needs to happen is a start from scratch. Java needs a class library that's sensible in all respects. It needs a performant, threadsafe collections library. It needs a GUI framework to replace Swing. The IO classes could use a good reworking, even beyond the java.nio.* classes. In short, Sun needs to throw away what they've come up with so far, and start from scratch. Except this time, they should do it properly. At this point, they do have two or three fuck-ups for each area they can learn from.

Re:The libraries are horrid.

[tkinnun0]

It needs a performant, threadsafe collections library.

public void processOneItem() {
if(collection.size() > 0) {
Object item = collection.elementAt(0);
collection.removeElementAt(0);
processItem(item);
}
}

How is a threadsafe collection going to help code such as this?

Apache Harmony - Open Source Java SE

[otisg]

I am surprised nobody mentioned Apache Harmony - http://incubator.apache.org/harmony/ - that's an open-source Java SE implementation.

Re:And HW accelerator licencing ...? ARM, AVR32...

[Big Jojo]

Let's not forget that the Java on cellphones, J2ME, is a small subset of J2SE or J2EE. The interpreter may not speed up too much J2SE code. J2ME API's (maybe VM?) seem to be open source already ...

My question isn't about J2ME or any blob of Sun code though. It's about actually having an open technical ecosystem. That said:

• subset ... no matter. Once you have the virtual machine, it's up to you what class libraries you put into it. Hardly anyone cares about the minimal subset of J2ME, except that it allows the Java(tm) brand without forcing all the J2SE/J2EE bloatware and legacy design crappola. Remember, those oldest Java APIs were written by people who really did not understand multithreading, efficient OO, or often even that much about Java.
• speed ... well now that's exactly the reason to want access to the hardware interpreter that's already present. That, and expecting the bytecodes to be a relatively efficient (and, one hopes, portable) program representation. That wireless handheld doesn't have gobs of memory or CPU to burn; the priority is long life out of a small battery. Efficiency is usually more important then speed.
• open source APIs ... don't care. Last I heard, programming interfaces (APIs) could not be copyrighted. Implementations could be, sure ... but having seen a lot of Sun's code, I certainly prefer the option of using something that doesn't target a 1 GHz machine with 1 GByte of RAM and 1 GPixel display ... since each of those numbers is around four to eight times too big for even a high end embedded handheld platform.

Remember that "run everywhere" mantra about Java? It would work a lot better if the runtime footprint of the JVM were bearable. For embedded systems, J2SE (and J2EE) are all but completely out of the picture. If the JVM core were all in the hardware, the rest of the system could be quite reasonably small ...

It would be interesting to know exactly how the chipmakers went about implementing the interpreters in hardware and/or firmware.

Hardware, not firmware. Some documentation talks about "bytecode accelerator", other docs are more explicit: there's a significant subset of the Java bytecodes that are directly executed by the hardware, just like "native" instructions. There's a CPU mode bit that says it's executing those bytecodes rather than the native instructions, and various types of context switches (irq, syscall, escape to native code, implement "complex" instructions in native code, etc.) will save restore that bit as well as other context in the Java thread.

So what's needed is to know what instructions are directly interpreted, how to perform the context switches, and similar stuff. Routine systems programming information, which Sun would stop locking down if it actually cared about an open programming ecosystem.

Nothing better to find in your stocking....

[CyborgWarrior]

Than an open jar of java beans.

Thank you, thank you, I'll be here all night!

Re:IBM (non)Trolls

[Big Jojo]

You don't need to be from IBM to be extremely skeptical about Sun's record of open sourcing Java. They have repeatedly promised to do that, and never done it. It's been many years now ...

Do you maybe recall the whole bit about pushing Java through ECMA? The reason that fell down is that ECMA required real openness, and Sun was unwilling to let the reins loose enough to achieve that. So they created their own quasi-open "Community Process", which they control to a degree that is completely incompatible with truly open standards. There are in fact checklists that must be followed to get an ISO standard mark, and many of the bullet items were things that Sun just refused to do.

People that are (still) pissed off at Sun about this are widespread in the industry, and are not just from IBM.

Okay, please run the stock up.

[Usagi_yo]

Okay, now that Sun is releasing the source to Java for free, they are sure to make millions giving it away. Please run the stock up so I can cash out.

Yes Johny,

[mano_k]

there is a Samta Claus!

Re:Yes Johny,

[mano_k]

Note to self: Don't post after sleeples night.
Yes, I should have use the fscking Preview Button.

Ok!

[crhylove]

Now Wake me up when Java stops sucking!

Re:Ok!

[Anonymous Coward]

Wake up honey... it's time to rinse the sperm from your mouth and pick my pubes from your teeth. Ahhh good. Now bend over like a good little bitch monkey like your daddy taught ya. MMMMmmm nice. Doesn't it feel *good* to have found your lot it life?

Advantage?

[Anonymous Coward]

Who is this going to be an advantage for?

The Java-people seem to be all keen on "one Sun way", screaming about how making Java open source is going to destroy it. That it will result in lots of incompatible versions.

The open source people who want to use a VM-based system are already using MONO. They haven't been sitting on their ass for years, doing absolutely nothing while waiting for Java to be open source.

The first group is going to hate the change. The second already regards Java as nothing more than a previous step in evolution of VM's, like Homo Erectus was for humans.

Re:Advantage?

[Anonymous Coward]

Mono? You can't be serious. Most "open-source people" are NOT using Mono, they are using Ruby, Python, Perl, and (gasp) even Java. The people using Mono are mostly Windows people who are new to Linux, since most "open-source people" do not trust Microsoft technologies like C#/.NET. Mono is really a hobbyist toy, it will never be fully accepted in the open-source community.

Re:Isn't the garbage collector supposed to minimiz

[delt0r]

Oh it does. If you have done a lot of programming in lots of different langs its hard to go back to non GC types. It really makes life easier. And no C++ does not have an excuse. You can use GC in STL and such as well.

Programming langs are tools! Not religions. Bad java is slower than proper C++. Poor C++ is hard to debug compared to well writen Java. Use the right tool for the job.

translation

[oohshiny]

Sun has already said that they were going to try to come up with an "open source" license that still prohibits "fragmentation"; but that's a logical impossibility, since the ability to fork a project is an intrinsic part of any license that can be called "open source".

So, "Java will be open source in 30-60 days" may simply mean that Schwartz will attempt to redefine the meaning of the term "open source" within the next 30-60 days to fit the source license they are already using.

Re:Isn't the garbage collector supposed to minimiz

[hr raattgift]

It's still easy to have memory 'leaks' in a language with a GC.

Only if you redfine 'leak' to be something other than data which is no longer reachable.

A precise collector will always correctly identify the liveness of data, because it knows what is a pointer into the GCed heap. (That is the definition of a precise collector).

A conservative collector is used when an object may or may not be a pointer into the GC heap (e.g., it may be a pointer into memory that is not to be managed by the collector, sometimes it may be another type of object entirely). Conservative collectors must err on the side of retaining possibly (but not provably) unreachable objects, and so can leak. However, for a number of years now, modern approaches such as barriers and generational scavenging asymptotically eliminate such retained dead objects from the managed heap, unless they are deliberately created. Such deliberation usually requires some effort, can be prevented by the compiler, is readily detected at runtime, and is easy to debug.

Bad programming practices can result in the growth of lots of live data. Typically this involves using global variables. Sometimes this is accidental, such as when the top-level retains a history of results returned to it for debugging purposes or other convenience. However, these are not leaks per se -- the data is live in that it is reachable. Making the data in question unreachable (reset the global variable or previous-results list) will allow either type of collector to reclaim the space.

In general it is much more common that memory is consumed by abandoned data that was created in heaps not managed by the collector, and these heaps are almost always used by code written in another non-GCed language. This includes the runtime, libraries, and foreign functions. Usually this is fixed via careful wrapping of the non-GC-language code with finalizers (exceptions, dynamic winding/unwinding, and other techniques), and in most GCed languages which expect to interact with things like the POSIX API this is usually done through libraries written in the GCed language.

Finally, some GC implementations, particularly conservative ones, are simply buggy or are not using modern techniques. In this case it's the implementation's collector leaking, not the language.

Article badly written ...

[hritcu]

... or at least written by a non-computer scientist who thinks open source is some sort of wagon. "The core platform [...] will be offered via an open source format"? "available via open source"? WTF ?

Re:Article badly written ...

[ADamiani]

So, are you saying it's less like a big wagon, and more like a series of tubes?

GUI vs multithreading

[hummassa]

It's easy to do anything withou making a blocking call.

Re:GUI vs multithreading

[Westley]

How, exactly? If you use non-blocking IO, then in many frameworks you'll end up being called back in a different thread - which leads to all the normal threading problems. Writing code using asynchronous IO is far harder than writing it using blocking calls - and harder, IMO, than writing a multi-threaded app using blocking calls.

Now, in certain situations an application really, really shouldn't use any blocking calls - but for a normal GUI, I'd far rather do long-running tasks in a separate thread and marshall calls back to the UI thread than try to make everything asynchronous.

Jon

weak post

[Anonymous Coward]

"Schwartz also commented on the companies Sun Fire servers",
would read much better if it said something like,
"Schwartz also commented on the company's Sun Fire servers".

VB

[Anonymous Coward]

What's wrong with VB ?

Excellent time to drop Mono

[HendrikIJzerbroot]

So, with that OSS argument against Java out of the way, can we drop the Mono desktop apps already?

Those .exe and .dll entries in my ps output gives me the shivers.

Re:Excellent time to drop Mono

[L'homme de Fromage]

Some of us have never used Mono apps to begin with. :)
Just curious, buy why are you running *any* Mono apps? I haven't seen one yet that wasn't a terrible bloated mess (on other people's machines). Java is pretty fast compared to Mono. And with the possibility of Microsoft enforcing their patents in .NET, the whole Mono project could be squashed at any time.

Re:Excellent time to drop Mono

[HendrikIJzerbroot]

Not by choice! Mono apps are creeping into the latest distributions. For example, my SuSE 10.1 runs Tomboy (yellow notes) and Beagle (desktop search) by default. I couldn't agree more with you - Mono is a waste of development effort. If MS doesn't outright kill Mono sometime, it will certainly sabotage portability.

Re:Isn't the garbage collector supposed to minimiz

[bentcd]

Only if you redfine 'leak' to be something other than data which is no longer reachable.
That depends on what you mean by "reachable". It is quite easy to end up with memory that cannot be reached from Java code but will never be collected.
This classically happened (and probably still does although I haven't checked for a while) if you forgot to call dispose() on GUI windows - the native GUI resource would not be freed because there is a piece of native code that hangs on to it until you call dispose().
Furthermore, you can easily "lose" your references into libraries that do not offer public access to them thereafter. For all practical purposes, these are not reachable from your code, although they certainly are reachable by the GC.

'bitrot'

[Randomly]

Is there a CPAN equivalent for Java?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Trolls Nonetheless

[javacowboy]

First of all, whether or not Sun goes through the EMCA has nothing to do with their track record on open sourcing stuff. That's a non sequitur.

Secondly, Sun largely (but not exclusively) maintaining control over Java means that they can continue to innovate with some measure of centralized control. Look what happened to JavaScript when it got EMCA'd.

Third, Sun has done absolutely nothing to prevent the FSF and the Apache foundation from working on their own open source Java implementations.

Fourth, Sun has invited a wide range of stakeholders into the JCP, including the Apache Foundation.

So what's the problem here?

Re:Isn't the garbage collector supposed to minimiz

[squiggleslash]

Only if you redfine 'leak' to be something other than data which is no longer reachable.

You mean redefine it back? A memory leak is simply a set of circumstances in which a program isn't freeing memory taken up by data that is no longer in use.

Whether that data is reachable is a slightly different, but related, issue. Data not being reachable yet remaining in memory certainly is one form of leak, because that is one set of circumstances in which unused data will continue to hog memory, but it's not the only one.

The misunderstanding that "unreachable" is the whole of memory leakage is one reason why automatic garbage collection should never be taught as a panacea. Regardless of whether you use it or not, you should work with it and ensure that you don't leave objects referring to other objects if there's no cause to.

That can't be right...

[crivens]

That can't be right - my wife already opened her new coffee maker on her birthday!

Look who's trolling now!!

[Big Jojo]

Secondly, Sun largely (but not exclusively) maintaining control over Java means that they can continue to innovate with some measure of centralized control.

Centralized control isn't "open". It means that Sun has the power to quash innovations it doesn't like, or delay them until they can't be as effective, or otherwise tilt the playing field. That's the point of the "control" after all.

Fourth, Sun has invited a wide range of stakeholders into the JCP, including the Apache Foundation.

While it has excluded an even wider range ... those too small to fork over the $$$ to join, or too open to agree to strangling discussions with non-JCP participants for a year or two before the JCP proposal gets to an all-but-complete late draft stage.

So what's the problem here?

Lack of openness on Sun's part. Providing some access to the source code, at this extremely late date, isn't much of a fix for a process that's fundamentally not open ... for a game that's stacked in favor of a certain model that hasn't even done all that well for Sun's shareholders.

OT, funny sig?

[BalloonMan]

"loose = advective, opposite of tight."

What's an "advective"?
People who can't spell shouldn't pick on other people's grammar.

Re:OT, funny sig?

[VGPowerlord]

Oops, typo on my part. I just added the adjective and verb parts to it last night. Apparently a bit too late last night.

ok, for a certain value of 'easy'....

[hummassa]

How, exactly? If you use non-blocking IO, then in many frameworks you'll end up being called back in a different thread

Or, an event will be fired to you indicating completion of a certain AIO. You'll pick up the event in your queue (all in _your_ pace) and indicate to the UI the completion of the IO, or to proceed with the computations. It's all a matter of having a really well-lubricated finite state machine....

Writing code using asynchronous IO is far harder than writing it using blocking calls - and harder, IMO, than writing a multi-threaded app using blocking calls.

Well, that's why they invented multithreading to start... but in some situations, you really simply can't have another thread. :-)
Seriously, this has been done a lot of times, with success.
In your others points, well, I agree with you.

Re:And HW accelerator licencing ...? ARM, AVR32...

[Big Jojo]

Ooh, I hate to reply to myself, but this is good news.

It turns out that Atmel just published the AVR32 Java Technical Reference Manual giving exactly the information I was asking about. Probably about 40 hours before I posted; sigh. I guess that Atmel guy was wrong when he said they couldn't publish that information ...

I've only skimmed those docs, so I can only say that they look like the right thing but clearly omit things like "how to invoke a synchronized method" (marked as TBD) ... but it's the first revision, and Atmel's pretty good about revising such stuff.

So part of my question is answered! Not the ARM part, which is too bad since ARM is the widely available platform, not AVR32.

VB

[Anonymous Coward]

I'd like to hear some *real* arguments against VB ...

Wonderful!

[Anonymous Coward]

Wonderful, a nice little toy programming language that I can give to the kiddies. Something they can be frustrated with, since it doesn't work, or come with everything I need to run it. One more 'toy' I can return to Santa, hopefully I kept my receipt.

Seriously, Java is nothing better than a toy, it should have been properly open-sourced years ago, maybe then, someone could have taken it to the same level as C, given it some rudimentary standards compliance, and done something useful with it.

As it stands, java is good for letting those too affraid to learn a "real" language, or harm their hardware, get some basic programming experience, at the cost of some of their sanity.