Slashdot Mirror

Seconded. For the longest time I hated Java, but lately I've been finding that Java is very nice for the server side.

As others pointed out, nobody uses the built-in time classes like java.util.Calendar. That one in particular is just completely unweildy. Everyone who needs to do anything with time and time zones uses Joda time. In fact, I've found when using JPA that I can't even involve java.util.Date or java.util.Calendar because they insist on persisting system-local time in the database. System-local time is utterly useless when you're writing an application that needs to support users from Newfoundland to Hawaii.

Oracle's ownership of Java was nearly a deal breaker for me, but fortunately there are things like icedtea. Essentially, Oracle is irrelevant as far as I'm concerned. My projects rely heavily on Apache Commons and other free software. In fact, it's the free software ecosystem surrounding Java on the server side that attracted me in the first place.

Of course, since this is Slashdot, half the comments here are decrying Java as a security risk and proclaiming its death because when they hear Java they think applets from the 90s and horrible Swing applications. Applets are dead. Flash killed them, and now Flash applets are dead, too. HTML5 is the future for client-side, but something has to serve the data for HTML5 to consume. I've found, especially working in a Windows shop, that Java fits the bill very well.

http://icedtea.classpath.org/wiki/ZeroSharkFaq

"What architectures do Zero and Shark work on?

As of December 2008, Zero is known to work on Alpha, ARM, IA-64, MIPS, PowerPC, x86, x86-64 and zSeries.

Shark should be able to build on any Zero-supported system that LLVM has a JIT for. As of October 2009, this is ARM, PowerPC, x86 and x86-64. "

You might be interested in http://icedtea.classpath.org/wiki/ZeroSharkFaq

GCJ really fulfills an entirely different purpose (compilation of Java to native binaries). If you're looking for an open source alternative, you could look at IcedTea, however Java is open source now so you could just use the original.

Your answer to "create free content" is "what if I get sued" ?

If you saw the number of times I accidentally used the two-measure hook from some song but caught myself before publishing, you might understand my fear of something slipping through. See Tainted Developer on Classpath's site, and then imagine a hypothetical world where almost no people in developed countries "have not studied the source code of the JDK/JRE" because the source code is broadcast over the radio.

Free content is already worked out. There's tons of freely licensed music, books, software, even movies out there today

What is an appropriate license for music in a Free game for a platform that has no file system, just 24 KB of EEPROM and 4 KB of RAM? Creative Commons licenses are incompatible with the GNU GPL due to interactions with the wording of CC's attribution requirement, and without a file system, it appears harder to take advantage of the GPL's "aggregate" exclusion.

Who mentioned programming Java? Only your fouled-mouthed troll.

Cyberax was talking about running languages such as Python, Ruby or Lisp on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM.

Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark.

Though Java-centric in nature, the JVM provides a secure sandboxed environment to host numerous languages including Ruby, Python, Lisp and even JavaScript. Throw in Groovy and Scala for home-grown alternatives.

Thanks to the efforts of IcedTea (principally funded by RedHat) and others, Java 6 will be fully GPL by the end of the year.

Try looking here: IcedTea. You can't always count on the primary source for your needs.

I'm using IcedTea on my 64-bit boxes; it isn't perfect, but it's good enough.

They joined forces with OpenJDK to give you some IcedTea http://icedtea.classpath.org/ that is the birthplace of many of the encumbrance removing. It bootstraps openjdk using gcj/classpath and replaces the still non-free blobs with code from GNU Classpath and adds a appletviewer - gcjwebplugin - and java webstart - netx - support.

The codebase? Java.

Back in the old days, Java was licensed with a scary EULA. This was fine for the end user because it was free as in beer. But it was trapped. OpenJDK is the cure. This is fine for end users and end developers. Now if a developer sees a bug (s)he'd like to fix, the license allows that.

Before Sun Microsystems released their code through OpenJDK, a rival GNU Classpath effort had been, and still is, producing a clean-room implementation. This prompted Sun to release their code under the same license in the hopes of cross-pollination.

The problem? Classpath and related projects have copyright assignment to FSF. OpenJDK requires copyright assignment to Sun. (Each, I think Sun does, may have copyright shared with the original author.)

So at the moment there's a something of a stand-off regarding this copyright. They're licensed under the same licensed but some code belongs to FSF and some belongs to Sun. So, effectively you either sell your soul to RMS or James Gosling! :) Ironic, given their bitter infamy over emacs!

Until lawyers of FSF and Sun can resolve this dispute, Classpath-derived code won't appear in OpenJDK and OpenJDK-derived code won't appear in Classpath. Third party repositories have been hosted for such hybrids. For the first scenario, IcedTea exists while for the second scenario BrandWeg has recently been announced. I quote the announcement for BrandWeg, which may be helpful in clarifying the issue:

It can host a variety of scripting languages such as Python, Ruby and, surprise, even JavaScript, as well as a couple home-grown languages such as Groovy and the purpose built JavaFX Script

Now before you shriek in horror at the thought of a JVM running in a web browser, Sun have made a renewed commitment to the browser via the soon to be released Consumer JRE, which aims to relieve some of the bloat and provide an improved experience.

Still no official 64 bit browser plugin but the IcedTea folks are working on a substitute.

The fine folks at Red Hat have been working on the IcedTea project to replace all the non-GPL'ed parts of OpenJDK with the appropriate bits from GNU Classpath.

The fine folks at Red Hat have been working on the IcedTea project to replace all the non-GPL'ed parts of OpenJDK with the appropriate bits from GNU Classpath.

No problem, we modify this problem in

http://icedtea.classpath.org/wiki//Main_Page
http://en.wikipedia.org/wiki/IcedTea_(software)

Will it be solved?

What lines are to be modified?

Else, "to reinvent the VM with a good isolation".

Java will have the same the same exception to GPL for its classlib as GNU Classpath, so the GPL will not have any effect on code running in the JVM. (It has even fewer restrictions than the LGPL that forces derived works to allow reverse engineering)

His problem is that he makes an assumption: that the 'linking exception' in GNU Classpath was introduced to make non-GPLd applications runnable with it, because otherwise linking would have been prohibited.

That assumption is wrong, but given how confused the poster is about linking, running, and their effects in the context of the GPL, it goes downhill from there.

For the real reason why GNU Classpath has a linking exception, see http://developer.classpath.org/pipermail/classpath /2006-March/000396.html

cheers,
dalibor topic

GNU Classpath actually has quite a bit of 1.4 and even some 1.5 features - http://builder.classpath.org/ has API comparisons. I have no idea where the 1.2 came from, it's probably just an outdated page in need of updating.

But the original question wasn't answered. Is this only concerning the VM, or the class libraries (which are currently released under the non-GPL compatible CDDL) as well?

Pluto is a planet of the hearts. Why define what constitutes a planet? We know by now that our universe is full of intresting objects which adhere to a solar cult. Pluto was always considered as the mysterious dark planet. And how should we call it now? A belt object?

Will researchers show up and tell us that Gnome, Suse, KDE and Classpath have no planets?

There are already free JVMs and free Java compilers. The problem is the class libraries. Java's standard libraries are huge, and free reimplementations are having a hard time keeping up. Without the libraries, open source versions of javac and the JVM won't bring us significantly closer to the goal of a completely free Java platform.

They can get heaps of working replacement code right from http://www.classpath.org/

Uhh.. Redhat *does* work on a Free Java stack. Look at the commits to http://www.classpath.org/ and that almost all of the gcj work is done by RedHat folks.

It is, but GNU Classpath is almost there (for J2SE 1.4 at least). For 1.5, there is a little more work to do:

http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15- classpath-generics.html

2: most java developers don't give a fuck about runtime environments other than suns and some of the platform isn't very well documented (just go and have a look at some of the stuff in javax.swing.plaf).

I work on the javax.swing.* packages in GNU Classpath, and Sun's "spec" here truly is woeful. We're trying hard to make sure the API documentation for GNU Classpath is more...informative.

In spite of the poor specification, GNU Classpath's javax.swing implementation is looking relatively good. The major missing piece (being worked on now) is a decent Graphics2D implementation (not strictly part of Swing, but a lot of Swing apps, and look-and-feels, need it). The text/HTML code still needs work too, but good progress is being made.

It is a shame that Sun has not released a free Java. All their arguments against it are hollow. Forks are good. Forks do not mean changes to the language specification. Most of the forks people want in Java are things like "Swing that uses Qt peers" or that kind of thing. Doesn't change a thing about the language, but it is a fork.

But it doesn't matter; some excellent free Java implementations are in progress.

They all rely on GNU Classpath (http://www.classpath.org/ which is getting closer to completion every day. In fact once they switch to their Generics branch I would be able to use it for most of what I do. And it works well with gcj, and I am quite impressed by what gcj does. It will let me write an application ONCE and then distribute binaries for Qt, GTK, and (presumably) MS Windows, and all these binaries will use the native toolkits. This is cool. One body of code, no ifdefs, no unholy makefiles, and I can support all the major platforms.

I realize that that day isn't here right now but it's getting close. I'm very excited about gcj and I am just about to start using it for some production tasks, like a background daemon that does some database updates, for example. No big deal, but it is "real world" use. Contempo.biz will use that for doing its calendar updates.

-----------
Contact management, scheduling, reminders, tasks, calendar, sales

Feedback wanted on how the different distributions are handling this, plus pacakge build instructions.

If you haven't seen the following they are pretty interesting...

ClasspathShowcase

GTK development in native eclipse

gcj support in HEAD OOo is simply using gij as a bytecode interpreter. Currently I've a trivial patch pending commit to use gcj-dbtool and gcj during buildtime to beforetime compile the java jars used during the build process itself. So during the build process I make use of the gcj native code creation cleverness, but not during runtime as yet. This is the sort of niftyness which gcj-dbtool and gij enable that I'm talking about.

You state "That would definitely make it competitive with .NET".

You should have say "That would definitely make it competitive with C#"

You can not compare a language and a platform.
C# might have some more feature, some of them nice but most of them are odd (made to be VB people friendly = bad reason ).

But if you compare the platform, .net lags years behind Java (From J2ME, J2SE or J2EE), from either community or enterprise perspective.

Looking all the new impressive domain coverred by the latest JSR, I don't expect the gap will be filled by MS. One of the main reason is that MS main plaform is Windows and not .net.

As a direct consequence, the will never bring all the feature at the .net level. Most of the valuable features (enterprise critics stuffs) will have to be keept at Windows level if they do not want to see .net as a potential threat for future windows market shares.

By the way, community guys if you thing that Sun implementation of Java is not free enough, please join the GNU Classpath (http://www.classpath.org) project. They are aiming to provide a libre GPLed implementation of the whole Java standard platform.

And according to the Java technology licensing, there is no way for Sun to prevent them doing that :) as long they keep the stuff compatible with the reference implementation (to check that they can get the TCK for nocost from the JCP because they are a .org ).

So, /.ers instead of trolling around "Open" Java, Go And Build It at GNU's Classpath /a !

No matter how good Gnome and KDE have gotten, if the .net and JAVA software is lacking (Mono is not nearly complete, and is exactly fighting this catch-up game, JAVA is a nifty SUN Trap)

Between gcj, Kaffe, JamVM, SableVM, all driven by the GNU Classpath library, experimental stuff like Jnode, and the massive wealth of Java code in projects like Eclipse and those driven by the Apache Foundation..

I'd say that Free java is alive and kicking. Yeah, it still hasn't become usable with respect to AWT/Swing. But most of the core is there, even up to some 1.4 stuff. (and work on 1.5 features is underway)

I don't buy the "catch-up game" argument. Most people don't write programs for the absolute latest and greatest. Platforms tend to reach a certain level of maturity which is 'good enough' for most people, and then it slows down. I think that soon enough, the free Java implementations will be able to compete with Sun's.

For example, how many compilers can you name which fully implement the C99 standard?

Everything is a catch-up game... it's just a question of what the game looks like. MS can arbitrarily change things in the Word file format just to screw with people. APIs don't work that way though, you don't change an API unless you have to.

Well, let me put it this way:

Yes, there are existing efforts at making a Free Software JVM/Java implementation - notably GCJ and Kaffe - and it is perfectly legal to do so. However, the big problem is reimplementing the whole Java API. Java has probably one of the biggest unified API's ever. Creating a compatible and stable implementation is not only a massive job, but also such an effort will be forever playing catch up! GNU Classpath is an admirable effort, relied upon by pretty much every GPL Java implementation, but just look at all the core stuff missing from the API!

If Sun GPL'd all its API, we could have a functional 100% free Java implementation right now, and they could still keep their own JVM tech proprietary, maybe sell it as a high performance option or something. Also, think of the improvements and bugfixes you'd get with thousands of people hacking on the class libraries?

As for forking the language, I think Sun could use its existing Community infrastructure to help tie development together and prevent this. Perl, PHP, Python, Ruby, etc are all open languages, yet forking is not a problem with them! As for Microsoft somehow doing evil stuff with Java - they have C# doing a good enough job at eroding Java already!

Another advantage to opening Java would be that distributions could include it in the base install. As it stands, if you want to run Sun's JVM, you have to go to their website seperately and download it. Even their download procedure itself can be a pain (especially on a server)!

Other people have blamed distros themselves for "religious" attitudes, but the fact is they simply aren't allowed to distribute JVMs, without at least adding all kinds of EULAs etc to the installer.

In my opinion Sun should:

• Preferably GPL the API
• At very least allow binary distribution by distros

If Sun opened it up, Java could become the base language of GNOME as detailed here. Think of how cool it would be to use a well established, modern language to write GNOME apps? And Sun would get even more of a foothold with their language.

Look at the bottom of the classpath page for a list of open source VMs that work with classpath (a free core (i.e., java.* and a few others) class library). All works in progress. I expect that mono and/or portable.net will quickly outpace free java projects. The JDK is a case where the availability of good enough gratis software has seriously hampered the momentum of libre competition. Netscape 4.x is another such case.

There are plenty of developer preference reasons for people to snub java. Up until recently, there were also freedom issues that had to be taken into account. But Classpath is coming along, and we already have Kaffe and at least one other Free JVM whose name I can't remember, not to mention all of the free software available through apache.

I wouldn't be too worried about linux being at a major disadvantage though - as linux commercializes, java will come whether die hards want it to or not. And even if it doesn't, it's not like java is going to take over the world. It may become a very widely used tool, but it's not like it's the only programming language that's going to be in use 5 years from now. In fact it might have faded into obscurity completely. Such is the 'puter industry.

It's in a early stage right now (version 0.0), but should more people hack on it, we can say bye-bye to Sun.

Both Japhar and GNU Classpath are active projects. Japhar could use more really good active developers, but the same is probably true for Classpath.

Can you give me contact addresses at Sun for Classpath and Japhar? I'm sure that Sun will be shocked to learn that these are under the LGPL.

This absolutely rocks. I have finally gotten my revenge on JWZ for all the mean things he said about Java.

If you were listening all those times, you would have heard me saying that I love programming in Java, I think it's a great language, and it's too bad that it's just not yet practical to write and deploy real end-user programs in it.

Having a Java front-end for a real native code compiler is a great thing, and an important first step. Once there's a corresponding complete Java runtime library (like the classpath.org folks are working on) then Java will be on equal footing with C.

But not until.

I'm looking forward to that day, because I really do think Java is a much better language than C or C++. My objections to it have always been that it's just not ready yet. I want to use it, but I can't.

This means that Java is now a real language, just like Objective-C, Pascal, Fortran, or C. The FUD official stops now.

What FUD? You're confusing "FUD" with "facts."

I think it's a damned shame how much Sun screwed this up. Java could have been genuinely useful years ago if they hadn't tried to maintain control so tightly, and hadn't tried to conflate so many completely different things (a language, an enormous class library, a virtual machine, and a security model) under one name.

And don't forget to check out the classpath project, which stands a better chance of getting Java2 features to linux in a reasonable timeframe.