The FreeBSD Foundation has negotiated a license with Sun to distribute binary versions of the JDK and JRE. Binary packages are currently available for FreeBSD 5.4 and 6.0 running on x86, with builds for other releases and platforms to be supported in the future.

From the announcement:

The FreeBSD Foundation is pleased to announce the availability of the official Java Runtime Environment (JRE) and Java Development Kit (JDK) for FreeBSD. The Foundation negotiated a license with Sun Microsystems to distribute these FreeBSD binaries. The binaries are based on JDK 1.5 and work with the official FreeBSD 5.4 and FreeBSD 6.0 releases on the i386 platform.

The FreeBSD Foundation provided financial support for Java development, funded the certification process, and negotiated license and trademark agreements to distribute pre-compiled binary packages of the Sun JDK and JRE.

Will this announcement help FreeBSD to become a more viable platfrm for hosting Java-based applications? Will leading Linux distributors be able to follow suit in a similar fashion?

Very good news, and congratulations to both parties (FreeBSD Foundation and Sun) on coming to agreement!

I think some of the Linux distributions already come with the JDK, and Sun (and IBM) already provides Linux-compatible JDK and JRE downloads.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Very good news, and congratulations to both parties (FreeBSD Foundation and Sun) on coming to agreement!I think some of the Linux distributions already come with the JDK, and Sun (and IBM) already provides Linux-compatible JDK and JRE downloads.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

It is very good news, and I hope that more Linux distributions can work to do the same.

Something that I occasionally get mildly annoyed about is the way that some Linux distros package products that provide binaries called 'java' that aren't certified Java. Several times I have got strange messages when trying to start apps because I have got my PATH wrong and not picked up the Sun or IBM binaries before the Linux-supplied binaries.

It is very good news, and I hope that more Linux distributions can work to do the same.Something that I occasionally get mildly annoyed about is the way that some Linux distros package products that provide binaries called 'java' that aren't certified Java. .

But I think that it is SUN's fault.

I could understand that they don't want to release Java under an Open Source licence. BUT....

Why don't allow to redistribute the binary JRE????

I think that this is slowing a lot Java's adoption in the Linux community. I really wish that debian or ubuntu could add Sun's JRE in their "non-free" repositories :-(

It is very good news, and I hope that more Linux distributions can work to do the same.Something that I occasionally get mildly annoyed about is the way that some Linux distros package products that provide binaries called 'java' that aren't certified Java. .

But I think that it is SUN's fault.I could understand that they don't want to release Java under an Open Source licence.

Sun have every right to do whatever they like with their product. Although I have great admiration for what is being done with open source versions of Java, I object to them being installed on my computers with binaries called 'java'. It is not Sun's fault that uncertified products are labelling themselves in this way.

Although I have great admiration for what is being done with open source versions of Java, I object to them being installed on my computers with binaries called 'java'. It is not Sun's fault that uncertified products are labelling themselves in this way.

How do you know they are uncertified? J2SE works via self-certification ;)

An executable named 'java' is required for a lot of free software applications, though, since their shell scripts refuse to start up otherwise. Distributors have got no choice there but to chose the name the software expects.

The open source versions tend to say quite clearly that they are not Java(TM), in my experience. Well, Kaffe does ;)

cheers,
dalibor topic

Although I have great admiration for what is being done with open source versions of Java, I object to them being installed on my computers with binaries called 'java'. It is not Sun's fault that uncertified products are labelling themselves in this way.

How do you know they are uncertified? J2SE works via self-certification ;)

I know because (at least in my experience, so far) open source VMs don't run software that I expect a JRE to run.

An executable named 'java' is required for a lot of free software applications, though, since their shell scripts refuse to start up otherwise.

But that is their issue, surely. By saying they need the executable 'java', they are implicitly requiring a certified Java implementation (whether they actually require it or not). This still does not mean that it is appropriate for incompatible implementations to label themselves 'java', does it, as many products expects a binary called 'java' to be compatible....

Distributors have got no choice there but to chose the name the software expects.

Yes, they have. They can ask the software writers to recognise that there are first-rate products that may not be fully certified, and to allow these products to detect and recognise these alternatives to the 'official' 'java'.

The open source versions tend to say quite clearly that they are not Java(TM), in my experience. Well, Kaffe does ;)cheers,dalibor topic

Good for Kaffe :) - it is a product I have been following with interest for a long time.

But, if the versions provide binaries called 'java', they clearly aren't saying (at least to other applications) that they aren't Java.

But that is their issue, surely. By saying they need the executable 'java', they are implicitly requiring a certified Java implementation (whether they actually require it or not). This still does not mean that it is appropriate for incompatible implementations to label themselves 'java', does it, as many products expects a binary called 'java' to be compatible....

They don't label themselves Java(TM), or Java(TM) compatible any more than Sun labels J2SE 1.5 itself as Debian GNU/Linux by having a tool called apt in it.

Or, to put it in more plastic terms, if you write a file whose name end in .java, that does not mean that your source code claims to be J2SE(TM), or J2SE(TM) compatible, or whatever. Or does it? ;)

Good for Kaffe :) - it is a product I have been following with interest for a long time.But, if the versions provide binaries called 'java', they clearly aren't saying (at least to other applications) that they aren't Java.

We don't do binaries on Kaffe.org, we leave that up to distributions. They tend to make a much better job of it than we could ever do. It's free software, and that's one of the great things about it.

FWIW, you can build Kaffe in a way such that the wrapper scripts that emulate the naming of Sun's tools for interoperability reasons are not installed, if it's causing a problem in your deployment.

Most distributions support ways to rebuild packages from source. See the output of Kaffe's configure --help for details. I can't speak for other VMs since I am not familar how they do it, but I assume it works similarly.

have fun,
dalibor topic

But that is their issue, surely. By saying they need the executable 'java', they are implicitly requiring a certified Java implementation (whether they actually require it or not). This still does not mean that it is appropriate for incompatible implementations to label themselves 'java', does it, as many products expects a binary called 'java' to be compatible....

They don't label themselves Java(TM), or Java(TM) compatible any more than Sun labels J2SE 1.5 itself as Debian GNU/Linux by having a tool called apt in it.

Oh come on! I have to disagree here! As the saying goes, if it walks like a duck, and quacks like a duck, it is a duck.... In the same way, if something is called a 'duck', you expect it to walk and quack in the appropriate way :)

I expect something called 'java' that is installed by a modern software distribution to be 'Java', or at least to do virtually all that a modern Java version does. When it doesn't, I think I am justified in being annoyed.

Or, to put it in more plastic terms, if you write a file whose name end in .java, that does not mean that your source code claims to be J2SE(TM), or J2SE(TM) compatible, or whatever. Or does it?

No, but I would certainly expect a modern Java version to be able to run such code. I don't mind if something that is not J2SE(TM) can also run it.

It's free software, and that's one of the great things about it.FWIW, you can build Kaffe in a way such that the wrapper scripts that emulate the naming of Sun's tools for interoperability reasons are not installed, if it's causing a problem in your deployment. Most distributions support ways to rebuild packages from source. See the output of Kaffe's configure --help for details. I can't speak for other VMs since I am not familar how they do it, but I assume it works similarly.have fun,dalibor topic

My view is that by default, they should not emulate the naming of Sun's tools, because if they do they are (in my opinion) at least to some degree misleading the user as to what they are and what they do.

I expect something called 'java' that is installed by a modern software distribution to be 'Java', or at least to do virtually all that a modern Java version does. When it doesn't, I think I am justified in being annoyed.

No, you are not. Not any more than someone decrying that gcc is available as cc and does not support some favourite piece of C99 that some random proprietary compiler does.

That's what the manual is for: learning your tools, and what they can and can't do. If you need some proprietary tool, you go and get that. You don't get annoyed because a distribution does not ship MSVC++ instead of gcc.

My view is that by default, they should not emulate the naming of Sun's tools, because if they do they are (in my opinion) at least to some degree misleading the user as to what they are and what they do.

Unless the user is deliberatly trying to be miseld, nope.

If you know that you need a certified J2SE implementation, then you know where to find it, and whether your distribution of choice ships it. If you don't know it, you can read the manuals, or use a search engine.

If you write an application that desperately needs to run on Sun's implementation, pay some cash to Sun to license it and ship it along. You'll save your users the hassle, and make Sun happy, to boot.

If you write an application that desperately needs to run on no-matter-which J2SE compatible implementation the user has installed, license the TCK from Sun, and run it upon the installation of your application. Only then can you be sure that the VM you have is indeed J2SE compatible in the specific context (libc, kernel, X, ...) of your installation.

cheers,
dalibor topic

No, you are not. Not any more than someone decrying that gcc is available as cc and does not support some favourite piece of C99 that some random proprietary compiler does.

That's what the manual is for: learning your tools, and what they can and can't do. If you need some proprietary tool, you go and get that. You don't get annoyed because a distribution does not ship MSVC++ instead of gcc.

No, because it is well understood that 'C' or 'C++' covers a wide range of implementations.

The term 'Java' means something.

Unless the user is deliberatly trying to be miseld, nope.

Sorry, but I completely disagree. A user downloads a Java IDE like NetBeans, types 'java' on a machine on which such a binary is installed as a dependency of another package, or because the user has generally requested development tools, and gets an error.

This is nothing but misleading. There is something called 'java' that does not do what the user expects 'java' to do.

If you write an application that desperately needs to run on Sun's implementation, pay some cash to Sun to license it and ship it along.

Don't need to. They can download it themselves. Hardly a 'hassle'.

I had assumed that the JRE could be shipped for free with any Java application. The problem was that it can't be shipped on it's own, which may happen for certain package selections on certain operating systems. However, I have no doubts that you know far more about this than me.

No, because it is well understood that 'C' or 'C++' covers a wide range of implementations. The term 'Java' means something.

It is an island.

The term java per se means nothing without a context. A distribution provides a context where that term has some specific meaning, like, you know, sh or cc or even $PATH. If it does not mean what you think it should mean, install something else. Distributions tend to make it easy to install and uninstall software.

A user downloads a Java IDE like NetBeans, types 'java' on a machine on which such a binary is installed as a dependency of another package, or because the user has generally requested development tools, and gets an error.

If the user has read the documentation, and uses the packaged version of NetBeans for his distribution, rather than downloading random binaries off the internet, ... then no, he never sees such an error. The packaging system tells him that he needs to satisfy a dependency, he does whatever that takes, and installs NetBeans from a safe, trusted, built-from-source build for his distribution, and signed off with a PGP key from someone whose identity can be verified.

The user *never, ever* goes off to grab unknown binaries off the web, unless he's really into getting '0wn3d'. In that case, he's got a much larger problem than what a java binary is called.

Distributions offer certain packages that work together well. If users download random binaries off the internet, and stuff breaks, it never the distribution's problem.

cheers,
dalibor topic

The term java per se means nothing without a context.

I disagree. It may mean nothing to you without a context, but to me it means something that is certified as Java. To me, this meaning is of great importance, as it helps me to be reasonably sure I know what I am getting. (OK, it also means a country and coffee, but you know what I mean).

A distribution provides a context where that term has some specific meaning, like, you know, sh or cc or even $PATH. If it does not mean what you think it should mean, install something else. Distributions tend to make it easy to install and uninstall software.

Well, my experience is different. Trying to uninstall Java from a distro I use mean that various other useful packages would have been uninstalled as well, unless I left broken dependencies. It was messy.

A user downloads a Java IDE like NetBeans, types 'java' on a machine on which such a binary is installed as a dependency of another package, or because the user has generally requested development tools, and gets an error.

If the user has read the documentation, and uses the packaged version of NetBeans for his distribution, rather than downloading random binaries off the internet, ... then no, he never sees such an error.

You may call the official distribution of NetBeans from their site 'a random binary', but I don't.

The packaging system tells him that he needs to satisfy a dependency, he does whatever that takes, and installs NetBeans from a safe, trusted, built-from-source build for his distribution, and signed off with a PGP key from someone whose identity can be verified. The user *never, ever* goes off to grab unknown binaries off the web, unless he's really into getting '0wn3d'. In that case, he's got a much larger problem than what a java binary is called.Distributions offer certain packages that work together well. If users download random binaries off the internet, and stuff breaks, it never the distribution's problem.cheers,dalibor topic

You don't trust NetBeans? Well I do - as their 'random binaries' come with a PGP key; and I also trust them as an organisation.

Distributions distribute software that's tested, works together well, and they can support. They also provide ways to manage the installed software, using the so called concept of "package management". They also provide lots of documentation, which is a great way to learn how the operating system works, and how to install software on it.

If you get some "screensaver.exe", "kournikova.vba" or "NetBeans.jar" outside your distribution's system to manage software, it is unreasonable to expect it to work out of the box, without spending some time reading the installation instructions and learning about how to get that software, and its dependencies installed.

If you want NetBeans in your distribution, and it hasn't been packaged yet, volunteer to help package it. It does not have to run on a free VM to be packaged. All distributions I work with have ways to say that a particular package still needs a proprietary dependency to work.

If you want a proprietary JVM integrated with your distribution, buy RHEL + RHN extra, which comes with packags for IBM's & BEAs VMs, afaik. Or Novell's, or Mandriva's commercial offers.

cheers,
dalibor topic

Distributions distribute software that's tested, works together well, and they can support. They also provide ways to manage the installed software, using the so called concept of "package management". They also provide lots of documentation, which is a great way to learn how the operating system works, and how to install software on it.

I know. I have been a fan and user of Debian for a very long time.

If you get some "screensaver.exe", "kournikova.vba" or "NetBeans.jar" outside your distribution's system to manage software, it is unreasonable to expect it to work out of the box, without spending some time reading the installation instructions and learning about how to get that software, and its dependencies installed.

Sorry, but I totally disagree. Firstly with you lumping a downloaded binary from netbeans.org with potential viruses - I think that is pretty outrageous, to be honest. Secondly, it is not unreasonable to expect it to work when clear instructions about how to install it are provided on the website. It is simple - providing, of course, a certified recent version of Java is installed, and not something masquerading as Java.

If you want NetBeans in your distribution, and it hasn't been packaged yet, volunteer to help package it.

There is no need to do this. A certified version of NetBeans can be downloaded from netbeans.org.

It does not have to run on a free VM to be packaged. All distributions I work with have ways to say that a particular package still needs a proprietary dependency to work.If you want a proprietary JVM integrated with your distribution, buy RHEL + RHN extra, which comes with packags for IBM's & BEAs VMs, afaik. Or Novell's, or Mandriva's commercial offers.cheers,dalibor topic

I don't need a JVM integrated with my distribution. I can download it in a few minutes from java.net.

Secondly, it is not unreasonable to expect it to work when clear instructions about how to install it are provided on the website. It is simple - providing, of course, a certified recent version of Java is installed, and not something masquerading as Java.

Let's say, for the sake of the argument, Debian distributed a proprietary, certified Java 1.1 implementation.

Let's also assume that I am so desperate for a proprietary Java 1.1 implementation, that I install that proprietary, certified Java 1.1 implementation via Debian's package mangement software.

Oddly enough, NetBeans still won't run, even though I have a certified Java implementation, which surely can't be accused of 'maquerading', now, can it?

Your complaint is not reasonable, as even the certified proprietary implementation have exactly the same effect as the free ones: NetBeans.jar just won't run. If you want to run it, you need to fullfil its dependencies.

If you want to help, you could help us package NetBeans for Debian. Or fix NetBeans to run on GNU Classpath. Or fix GNU Classpath to run NetBeans.

cheers,
dalibor topic

Secondly, it is not unreasonable to expect it to work when clear instructions about how to install it are provided on the website. It is simple - providing, of course, a certified recent version of Java is installed, and not something masquerading as Java.

Let's say, for the sake of the argument, Debian distributed a proprietary, certified Java 1.1 implementation. Let's also assume that I am so desperate for a proprietary Java 1.1 implementation, that I install that proprietary, certified Java 1.1 implementation via Debian's package mangement software. Oddly enough, NetBeans still won't run, even though I have a certified Java implementation, which surely can't be accused of 'maquerading', now, can it? Your complaint is not reasonable, as even the certified proprietary implementation have exactly the same effect as the free ones: NetBeans.jar just won't run. If you want to run it, you need to fullfil its dependencies.If you want to help, you could help us package NetBeans for Debian. Or fix NetBeans to run on GNU Classpath. Or fix GNU Classpath to run NetBeans.cheers,dalibor topic

My complaint is reasonable, because with certified Java implementations, you know what version of Java they are certified for; that is the point. What I am objecting to is software that isn't certified providing something called 'java'.

Yet again, the requirement for a certified modern Java is not a sign of desperation - it is the reasonable need to be able to run modern development tools and use the same APIs and libraries that millions of other developers use.

If I had time, I would love to help with GNU Classpath or a similar project. However, it is not a priority because I don't require that all my software is packaged as part of a Linux distribution. I may be naive, but I actually trust certain organisations and vendors, like NetBeans and Sun, to provide quality software that won't mess up my computer.

It is very good news, and I hope that more Linux distributions can work to do the same.

That's unlikely.

In order to freely distribute Sun's VM, someone needs to pony up the cash, time & resources for certifying it on the respective platform. Most volunteer-run distributions don't have resources to spend on that, and tend to have no trouble finding better things to do with the limited resources they have.

You can't just put Sun's proprietary JVM implementation on an FTP server (legally), since the BCL does not allow free, unencumbered redistribution. Sun's BCL license only allows redistribution in special cases, that make no sense for free software operating systems distributions.

As a distribution, therefore you need a contract with Sun covering trade marks, re-distribution rights, allowing you to make modifications for packaging, etc. It's not a trivial matter, and you need to spend some serious money on the lawyers to avoid leaving yourself open to interesting post-facto 'interpretations' by Sun's legal. See this thread on the "NOTICE FROM SUN MICROSYSTEMS" for a lesson on that.

Otoh, commercial GNU/Linux distributors (Sun, Red Hat, Novell, Mandrive) have real, (presumably expensive) contracts for redistribution, since they can have a financial benefit from providing proprietary Java implementations to customers that pay for it (for example, via subscriptions). They also can afford to have their lawyers hammer out legal agreements with Sun that don't hold surprises.

Beside the legal issues, there is also the issue of forcing redistributors to pay Sun for a license to use of the Java trade mark, which you have to do if you are an OEM distributing FreeBSD + the respective port of the proprietary Java implementation. Volunteer-ran distributions are unlikely to enter such agreements, since they have no interest in attaching an obligatory redistribution fee on their works, in general, as proprietary implementations are readily available from Sun, IBM, and the likes. Uncertified for the distributions, but still working passably, which is what people really care about, in my experience.

So asymetrical, 'single-node' redistribution agreements are not going to work well for Debian, Ubuntu or Fedora, and entering them is unnecessary for the distributions since the users who desperately wish to run a proprietary JVM can do and get one from one of the proprietary JVM vendors.

cheers,
dalibor topic

since the users who desperately wish to run a proprietary JVM can do and get one from one of the proprietary JVM vendors.cheers,dalibor topic

I think this is a bit harsh - after all, users who want to use a modern IDE like NetBeans, or develop with Swing, or use Java 1.5 features are hardly unreasonable - it is not a 'desperate wish'. Or am I out of date, and are there open source implementations that can do this now?

I think this is a bit harsh - after all, users who want to use a modern IDE like NetBeans, or develop with Swing, or use Java 1.5 features are hardly unreasonable - it is not a 'desperate wish'. Or am I out of date, and are there open source implementations that can do this now?

NetBeans is still out of reach. Maybe later this year. If you are interested in making it work, I'd recommend starting with the NetBeans RCP and working your way up the stack.

Swing is coming along quickly, see Roman's posts at http://kennke.org/blog/blosxom.cgi/ . 1.5 support is in IKVM and JamVM. Some parts have been checked into Kaffe recently as well, so I expect that most open source VMs will move to full 1.5 support later this year. Fun times ahead.

cheers,
dalibor topic

Some parts have been checked into Kaffe recently as well, so I expect that most open source VMs will move to full 1.5 support later this year. Fun times ahead.cheers,dalibor topic

That is impressive! I did not realise that open source VMs were so advanced.

Does that mean Apple users finally get JDK 1.5 available ???

no need to compile from source... !!!

The value here is that you no longer have to build the binaries from source which always was a PITA process that took several hours and often failed. Users are now able to run the binaries and app servers on boxes without the difficulty of getting everything going from scratch.

From my experience, FreeBSD boxes are much easier to maintain than Linux boxes are perform much better as servers. Often in the past I have had clients who would not deploy on FreeBSD because of these challenges.

Justen Stepka
Authentisoft - Single Sign On. Simplified.

I dont use linux I dont use Solaris I dont use windows :) i only use *BSD ...and for me it's an all time great news

cheers !!

I love FreeBSD it is a real Unix not a clone.
it is very secure.
it is robust.
It is Free!
from now on. I will ship all my later Java programs on BSD
I hope this will help other flavors of BSD like OpenBSD and NetBSD to better support of Java.