Sun yanks FreeBSD's Java license
Even after receiving notice of the termination of our license attempts to contact Sun to renegotiate the license have gone unanswered. For now, it is safe to assume that the Foundation will engage in another lengthy, and potentially costly, licensing negotiation before our binary distributions can continue."
Posted Jan 10, 2005 14:57 UTC (Mon)
by tomsi (subscriber, #2306)
[Link]
Tom
Posted Jan 10, 2005 16:21 UTC (Mon)
by cpm (guest, #3554)
[Link] (20 responses)
Posted Jan 10, 2005 17:31 UTC (Mon)
by mmarq (guest, #2332)
[Link] (19 responses)
The Open Standards Group, Linux oriented API/ABI, which includes the GNU runtimes are 1000% more important than the Java VM... "everybody" use it, BSDs use it, SUN use it, even SCO use it, and it can support x86, x86_64 PPC32/64, sparc32/64, IA64 ... and better it includes a compiler for the Java language so if you are a Java developer you *should* compile it to the metal, because it can easely be made to run on *everyone* of the fundamental architectures and OSes.
" IMO it can esaly be made to function on Microsoft Windows, if people start to see the wisdom, of shell replace the intire Microsoft Windows environment with a "free" one that can do NFS, Xwindows,... and of course be LSB compatible... IT WOULD BE A TURNING POINT IN THE IT PARADIGMA... for sure. "
And if the support for a particular architecture or OS is not good enough, than people IMO should try to help fixing/improving the API/ABI instead of jumping head first to be a hostage of SUN/Java or Microsoft/C#.
Posted Jan 10, 2005 18:47 UTC (Mon)
by mrshiny (guest, #4266)
[Link] (18 responses)
Frankly, I wouldn't be surprised to see MORE stuff being virtualized as just-in-time compilation becomes better and better. But I digress.
Java is much, much more than cross-platform compatibility anyway. It is incredibly useful, widely supported in industry, and has an array of fantastic tools to support development and deployment. Running native Linux binaries? No thanks, it just doesn't compare for the jobs Java does well.
Posted Jan 10, 2005 22:36 UTC (Mon)
by landley (guest, #6789)
[Link] (5 responses)
Lots of stuff uses bytecode today. The only "advantage" java has over a modern interpreted language like Python is the ability to distribute closed-source binaries (and a few years head start on optimizing the runtime. Woo. I did animated graphics in java on a 486 and figured out how to get decent performance in 1998. Work just loaned me a brand new 1.6 ghz Pentium M).
Java _is_ dead in the open source world. See Johnathan Schwarz's blog:
> Now, I had a parallel set of interactions at this year's JavaOne, at
As usual, Schwartz missed the point completely. Open source coders don't use java anymore, thus they aren't at JavaOne. We abandoned it years ago after Sun refused to hand the langauge over to a standards body, after "no Linux JDK" was the #1 bug on java.sun.com with five times as many votes as any other bug and Sun completely ignored it for over a year, after the Sun guys abused the Blackdown developers to the point where most of them quit, after the "Sun Community License" where looking at the source taints you in perpetuity showed they just didn't get it...
Posted Jan 11, 2005 0:14 UTC (Tue)
by dang (guest, #310)
[Link] (3 responses)
Posted Jan 11, 2005 1:32 UTC (Tue)
by khim (subscriber, #9252)
[Link]
I had. A lot of trouble. With resolver, with threads, etc, etc. To the level when we discussed switch to Windows (where problems are not so acute) or rewriting everything in C/C++ (where we at least can properly debug problems).
Posted Jan 11, 2005 20:55 UTC (Tue)
by error27 (subscriber, #8346)
[Link]
It's not just that the Free java tools suck, it's that they suck in different incompatible ways. Code that works under gcj doesn't work with jikes and vice-versa.
At least if you use Mono under Linux and you distribute your code to someone else who uses Mono under Linux then you have a chance the the code will run on both systems.
For massive dedicated installations you just install Sun's non-Free JAVA, do your work, get paid and try to find something fullfilling to do in your free time. That's OK. But I still see java used for stuff like ICQ clients and source code analysis tools and people expect them to work under Debian. That's just not happenning.
Posted Jan 12, 2005 8:23 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
Freedom doesn't mean freedom to run on vendor-approved hardware only -- it means freedom to run the code ANYWHERE, even if it's an old m68k Amiga.
Posted Jan 11, 2005 4:57 UTC (Tue)
by cajal (guest, #4167)
[Link]
That, and Java's VM is lightyears more advanced that CPython's. Python has a global
interpreter
lock, so it's hard to scale it up, thread-wise. It's unable to defragment its heap and release
unused memory back to the OS. It doesn't have generational or parallel garbage collection.
It
doesn't natively have a JIT, nor does it profile code as it runs for further optimization. It's not
possible to write lock-free algorithms in Python Python is one of my favorite languages, but for enterprise work, it just doesn't hold a candle
to
Sun's HotSpot JVM or IBM's JVM.
Posted Jan 11, 2005 10:20 UTC (Tue)
by brianomahoney (guest, #6206)
[Link] (2 responses)
BSD and the Linux distribution vendors are NOT Microsoft, and so preventing them from distributing a configured Java environment just means that Java is a hassle to install and use.
Corporations, and SUN in particular must learn that 'linkage' will no longer work in an environment where software is commoditized; SUN have, unfortunately a long history of this eg the C compiler, Java on SunOS.
Finally, as was said in another forum, and entirely contrary to what the poster said, complex tookits doom more projects than anything else.
Posted Jan 11, 2005 20:24 UTC (Tue)
by mmarq (guest, #2332)
[Link] (1 responses)
But they are a thing of the futur: http://www.alphaworks.ibm.com/tech/rib?open&S_TACT=10...
It is just that the traditional look and feel of Java Apps happen to suck so immensely...
But my real point, concerning toolkits voted to widgets and "apperence" in general, it has yet to be field the promise of a easy and strinking usefull way, in any OS environment out there, of separating the GUI out of the executing body of the application and associetated librarys. Toolkits are intermingled badly with the languages and implementations.
What is needed,IMO, is a IDL, like in OS2 example, or a much better one, that can "speak", a compatible Qt version, along with a compatible GTK version, along with...
Yes i'm asking for the "impossible" of making the relative "extremely" easy task of making a Qt or a GTK or a Java toolkit,... compatible with each other by means of an IDL that as a "metatoolkit" implementation as a reference. The idea is not the metatoolkit completly "eclipse" the others, but the others incorporating the directives and code of the metatoolkit, so that any application have the same look&feel, and yes, it can be there applications with GUIS that are based on one toolkit but have some widgets or dialogues of another toolkit... can it be done?
Posted Jan 13, 2005 9:39 UTC (Thu)
by rjw (guest, #10415)
[Link]
Posted Jan 11, 2005 19:14 UTC (Tue)
by mmarq (guest, #2332)
[Link] (5 responses)
Yes, i already knew that.
But my point is that, can't it be made to be the other way around ?... whitout altering the syntax, and without inventing a new language?... i belive that theorectly it can be made possible...
" Frankly, I wouldn't be surprised to see MORE stuff being virtualized as just-in-time compilation becomes better and better. But I digress. "
Unfortunatly i have to digress also in that direction... for the time being. But i still see the advantage of VMs or JITs only has that of "writing once and run everywhere", nothing else. And i understand that in the actual software/hardware status quo, powerfull enough hardware and boxed software the trend to lower prices will make VM and JITs a fundamental "economy of scale" piece. But if Open source has to have the majority of market, then "taylor made" software will be definetly a plus, and "optimizations" will win over "economy of scale"... it makes sense, to me at least... otherwise i digress even more.
Posted Jan 11, 2005 22:29 UTC (Tue)
by mrshiny (guest, #4266)
[Link] (4 responses)
My point is that the actual performance of the running product is FASTER in some cases when you use Java than when you use C++ or C or Perl or whatever. Not all cases. But as runtime compilation techniques improve, you will see more and more stuff 'virtualized', whether it's C or whatever. But Java is already doing this today. It may not be faster for everything, but people who use Java know how fast it is, and what it's good for. Compiling java code to a native format would not provide any advantage for me, so why should I do it? Free software idealism? No thanks. I'm in favour of a Free-software implementation of the JVM, but GCJ will not be useful to me until it performs as well as the JVM.
And "Write once, run anywhere" is ONE benefit, but not the only benefit of Java. Java is also a nice programming language; I like it much better than python or C or C++ or Visual Basic. Java has a very nice class library and lots of good, enterprise open-source products. Java makes lots of things easy, like reflection, remote-debugging, etc.
Finally, tailor-made vs economy of scale... I think Open-source can accomplish both. And I think Java is a good tool to use for both kinds of jobs. Some popular client apps are java, such as Limewire (not hugely popular, but still fairly popular). Limewire isn't open-source, but then there aren't lots of open-source desktop programs that aren't gtk or QT. A notable exception is Eclipse: a very popular IDE for Java and C++ development that is written in Java. It's a great program and lots of developers use it; IBM even resells a closed-source version as their primary development environment. Also, lots of custom-made software is Java. Some of that is open-source. Basically it's all about using the right tool for the job. And Java is a very nice tool, and to a lot of people it's definitely the right tool.
So I'm not sure how arguments about custom software vs off-the-shelf software are relevent to the whole "Java or not" question. I'd say the question should be about the technology. But unfortunately Sun are turning into crackpots and I am worried that they may harm the Java platform with their politics. But rest assured that if Sun goes down in flames, someone will rescue Java, one way or another.
Posted Jan 12, 2005 2:00 UTC (Wed)
by mmarq (guest, #2332)
[Link] (3 responses)
No !!... the other way around is that the compiled native form of Java can be made to run as fast or much faster than the bytecode form on a VM... it isn't today with GCj but it could very well be. It needs to improve dramaticly the executable native form "code" that the compiler spits.
For the developer this is an almost interely transparent change. The same applyes to C#.
" My point is that the actual performance of the running product is FASTER in some cases when you use Java than when you use C++ or C or Perl or whatever. "
When it comes to time sharing computation it is possible that a very optimized form of virtualized code, like Java bytecode on an VM or JIT, dont take any mesurable penaltys over a native compiled form. But when it comes to real time solutions, soft or hard real time solutions, when applications need to do data streaming(video, audio, animation) without hicups, or even when they do intensive graphics, like in next generation 3D Desktops. Then a VM or a JIT, be it of Java or of any other language yet to be invented or not, seems to me to be an inadquate approach. Why wast resources on another layer of indirection, be it a VM or a JIT ?, why take the overhead ?...
And real time aware applications, intensive graphics, streaming data, with integration of VoIP, videoconference, whiteboarding in groupware solutions, *real* 3D Desktops and application, streaming music and movies over the internet... will be just everywhere in server, desktop and embeded!
All this dont displace Java. It only means that a powerfull native form compiler would be a very well comed addition to all those that love and program in Java, not out of idealism but out of necessity.
Posted Jan 12, 2005 8:47 UTC (Wed)
by piman (guest, #8957)
[Link] (2 responses)
The kind of optimizations in question can't be done in the "bare metal" compiler. The kinds of problems range from simple things like complex instructions sets such as SSE, to runtime profiling and adaptation to avoid branch mispredictions, to automatic generation of optimized per-type versions of generic function calls. None of these can be done at the traditional compile time, they all depend on very specific implementation details of the CPUs in question, and even on the runtime datasets.
You can push these off if you like, but all that happens is that the slack gets picked up in the hardware end -- branch prediction is a primitive example of this, or on a more advanced level the Transmeta Crusoe which runs everything on a transparent JIT of sorts.
The trend is for JIT compilers to get faster and faster, and as more of the above techniques come into play, there's no reason to assume native code can keep up.
Posted Jan 12, 2005 21:39 UTC (Wed)
by mmarq (guest, #2332)
[Link]
Are you telling that Java the Platform dosent allow to take advantage of all those special CPU features, different from architecture to architecture, as it can be done with the C compiler... so a "compiled to the metal" dosent take any mesurable advanyage over the VM bytecode ?
I'm not a Java programer or expert, but isn't that because the language is so focused in "crossing-platforms" by a "lowest common denominator" that is the JVM ?...
So perhaps changing Java the Platform(not only an open source VM implementation), in a way that the generated bytecode will be compatible with *TODAY* JVMs out there, and the native code can take advantage of all CPU features. And all this without changing the language sintax, and inventing a new language altogether?... no !?
Can of worms?... but isn't there already a can of worms in the mess of Java implementations? And with SUN going for the moon back and foward, things trend to get worst.
The advantadge is to link 'earlyer' to all those other pices of code that run in the metal like the OSes, Qt or GTK toolkits, OpenGL primitives,etc.. and make Java aplications swift and time aware, being able to make real time Java applications. The cross-platform will be assured by a compatible API/ABI across the different OSes and CPU architectures, and the 'old' Java (JVMs) behavior will be achived *simply* by compiling to bytecode and linking 'late' with all the pieces compatible.
Yes,... except for Web-services and other highly dynamic and mobil applications the VM importance and possibilitys will be void,... but isn't that already ? The change will be a major improvement to all those that love and program in Java.
"" At the end of the day, can or cannot, a Java program in an "optimized" binary executable form, linking ignored, be made to be as fast or "much" faster than the form in optimized bytecode, being the source code "equal" in both cases ??... ""
Posted Jan 12, 2005 22:44 UTC (Wed)
by mmarq (guest, #2332)
[Link]
" The trend is for JIT compilers to get faster and faster, and as more of the above techniques come into play, there's no reason to assume native code can keep up. "
But isn't that Microsoft dream ? Make "cross- platform" in a layer below the OS (instead of the natural above OS API/ABI runtimes and librarys), and all 'possible' languages depending on a *common runtime* (CLI), specialized in 'NONE' particular computacinal task. So far it has proved to make a lot of applications sluggish, specialy the OS...
IMHO, is more like a pipe dream, because Microsoft is a control company that hasen't been able to control effectivelly the Hardware Industry. But if they manage to pass about *all* applications to the new JIT platform, then perhaps they can spark the *rush* in the industry, in a new CPU war, to make CPUs that run the JIT internally, instead of the normal optimized microcode. And then Microsoft, because they effectvily control the JIT functionaly no matter if the runtime is pseudo open sourced, could not only charge royalties from every CPU made, but also have the chance to exclude applications and OSes they dont like!!...
SUN had an identical dream, and because they have the facilityes, they even have made CPUs, the Java CPUs, that run the bytecode directly in metal, i belive. They have failed rotundly, and one of the reasons is performance penaltys, because optimized microcode is a totaly different story..
There are the opposite where Assembly is just about making microcode directly into a programing language, but that would make programming worst then a nighmare,...if you have to build an Office package. So it seems that all this layers from microcode to "no lines of code needed" programming IDEs and languages, have the nasty tendency to stay inside their optimized borders, and VMs and JITs, no matter the language sintax and structures, are only real usefull for a 'fast and easy' cross-platform business,... internet has been one of such bussineses of sucess. With streaming and real time needed applications VMs and JITs, IMHO, will trend to lose a lot of usefulness.
Posted Jan 11, 2005 22:00 UTC (Tue)
by man_ls (guest, #15091)
[Link] (2 responses)
Your only advantage with the JVM is to be able to distribute opaque "binaries"; but, since .class objects are trivial to decompile, it's not much of a protection anyway. Distributing precompiled gcj binaries would actually be a much better obfuscation.
Posted Jan 11, 2005 23:12 UTC (Tue)
by robilad (guest, #27163)
[Link]
cheers,
Posted Jan 12, 2005 8:50 UTC (Wed)
by piman (guest, #8957)
[Link]
Posted Jan 10, 2005 16:33 UTC (Mon)
by ami.ganguli (guest, #9613)
[Link] (5 responses)
I really don't understand Sun's strategy. Why are the limiting binary distribution of something they give away for free (beer) anyway?
Posted Jan 10, 2005 17:47 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
They want to control it. They do not like kaffe, gcj or some other uncontrolled surrogate to replace their implementation. Thay are using a lot of tricks to do so. Kinda shows you what you'll be getting if you'll buy into "open-sourced solaris" thing
Posted Jan 11, 2005 7:43 UTC (Tue)
by eru (subscriber, #2753)
[Link]
But that is precisely why Sun's attempts to limit the binary distribution of
their own Java implementation are so weird! If Sun ensured
that every platform had a well-working JVM and JDK in binary form with easy
licenses, so all vendors/distro makers/BSD projects could include it
without problems, very few people would be interested in kaffe, gcj etc.
Posted Jan 10, 2005 17:50 UTC (Mon)
by mmarq (guest, #2332)
[Link] (2 responses)
I belive they want everybody to download the SUN Java pack, out of SUN sites, as a marketing strategy... Since there are already much less bloated and as good or better than SUN, Java VMs and JIT out there... they, SUN, want to score points has inventors of the language .
Posted Jan 11, 2005 10:04 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
There are good java compilers; but there is currently no effective competing VM or JDK to my knowledge (not least because Sun's implementations of the VM and JDK have an incestuous and undocumented interrelationship so you effectively can't reimplement one without reimplementing the other, too).
If there is one, please tell me what it is: I'd like to get rid of the last non-free software on my machine.
Posted Jan 11, 2005 11:44 UTC (Tue)
by dmantione (guest, #4640)
[Link]
However, it is just as propietary as the Sun JDK. However, I have more respect for IBM than I have for Sun, so I'm using that one.
Posted Jan 10, 2005 18:31 UTC (Mon)
by lseubert (guest, #4168)
[Link]
Posted Jan 10, 2005 19:05 UTC (Mon)
by bluefoxicy (guest, #25366)
[Link] (6 responses)
On Linux, we can just tell Sun to screw off. Too bad Blackdown isn't a BSD thing, or an OSS thing. BSD will just have to wait for Kaffe.
Posted Jan 10, 2005 19:07 UTC (Mon)
by bluefoxicy (guest, #25366)
[Link] (1 responses)
Posted Jan 10, 2005 19:35 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Sun can easily revoke BlackDown's license as well.
Posted Jan 10, 2005 19:37 UTC (Mon)
by marduk (subscriber, #3831)
[Link] (1 responses)
Posted Jan 11, 2005 22:57 UTC (Tue)
by robilad (guest, #27163)
[Link]
People spent a year merging in almost everything remaining from GNU Classpath, GNU Crypto, GNU JAXP, Gjdoc, and other free class library efforts, adding ports to new platforms (one new port for freebsd, actually), making eclipse 3 run, and such nice little things. Now to stabilize things a bit more, and you can play with it on your favourite platform. CVS head is pretty lively ;)
cheers,
For latest status, hop on #kaffe on irc.freenode.org is where the action is happening, largely.
Posted Jan 10, 2005 21:00 UTC (Mon)
by jd (guest, #26381)
[Link]
Posted Jan 10, 2005 22:07 UTC (Mon)
by bojan (subscriber, #14302)
[Link]
Posted Jan 11, 2005 0:03 UTC (Tue)
by armijn (subscriber, #3653)
[Link] (1 responses)
Posted Jan 11, 2005 1:39 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Of course. The problem is not "if Sun made such move out of malice". The problem is that Sun was able to do this - and it's quite real problem: if tomorrow Sun will have "change of heart" and will recall all licenses... - there are literally nothing that can be done in short term. RMS long ago written about it here. Looks like he was right after all...
Posted Jan 11, 2005 2:59 UTC (Tue)
by huffd (guest, #10382)
[Link]
As long as Java is not properly licensed to benefit all. Sun can manipulate ANY of it's competitors.
Having worked with both, you'd be far better off using MONO.
Posted Jan 11, 2005 7:37 UTC (Tue)
by mjw (subscriber, #16740)
[Link]
Try it out. It might be the Free Software alternative that you are looking for if you fell into the java trap.
I have found another comment on the case here http://www.infoworld.com/article/05/01/06/HNfreebsdsun_1.htmlSun yanks FreeBSD's Java license
When are folks just gonna get tired of Java, and just stopSun yanks FreeBSD's Java license
this silly silly game?
Agreed 200%...Sun yanks FreeBSD's Java license
Nobody who uses Java would claim that GCJ is a better Java than Java. Compiling "to the metal" is actually a disadvantage, since the JVM is faster than the compiled code. Also, you have to distribute binaries for multiple platforms, and you lose optimizations available when the JVM improves its runtime compiler.Sun yanks FreeBSD's Java license
You mean like the way Python and Perl run all their files by compiling the source to bytecode at runtime, and then running the bytecode? (Python will even save a snapshot of the bytecode for libraries, if the directory is writeable.) Bytecode dates back to (at least) Pascal p-code in the 1970's, which had the disadvantage of being Pascal and running on 1970's hardware where assembly was still a good idea.Sun yanks FreeBSD's Java license
http://blogs.sun.com/roller/page/jonathan/20041021
> which a bunch of friends joined us for a discussion on the open sourcing
> of Java. Among the luminaries present was Brian Behlendorf, who opened
> his statements by asking what I'm sure he felt was a question with a
> popular answer, "How many of you work on an open source project?"
>
> I expected to see a flurry of hands, and I'm sure he did, too.
>
> Neither of us saw hands go up.
>
> The community represented at JavaOne either worked within the Java
> Community, or were developers with other issues on their minds (like
> their day jobs). Interesting.
Odd how I've never really had any trouble running Java on linux for years.Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
If you only run Free software then Java is a reall pain.Sun yanks FreeBSD's Java license
Things get worse very very fast if you dare to use amd64, or powerpc, or ...Yeah -- no problems at all. On i386.
Sun yanks FreeBSD's Java license
The only "advantage" java has over a modern interpreted language like Python is
the ability to distribute closed-source binaries.
The simple point is that SUN cannot be trusted, it seems, to play nice in the community, and they cant have it both ways.Sun yanks FreeBSD's Java license
"... complex tookits doom more projects than anything else. "Sun yanks FreeBSD's Java license
http://channel9.msdn.com/ShowPost.aspx?PostID=34528
Take a look at methatheme.
Trying to solve the look-and-feel bit of the problem.
Sun yanks FreeBSD's Java license
" Compiling "to the metal" is actually a disadvantage, since the JVM is faster than the compiled code. "Sun yanks FreeBSD's Java license
Are you saying that we should virtualize existing languages? Or that we should make cross-platform java? I'm not really sure what you mean about doing it "the other way around". Sun yanks FreeBSD's Java license
" Are you saying that we should virtualize existing languages? Or that we should make cross-platform java? I'm not really sure what you mean about doing it "the other way around". "Sun yanks FreeBSD's Java license
> It needs to improve dramaticly the executable native form "code" that the compiler spits.Sun yanks FreeBSD's Java license
" None of these can be done at the traditional compile time, they all depend on very specific implementation details of the CPUs in question, and even on the runtime datasets. "Sun yanks FreeBSD's Java license
A late one...Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
Nobody who uses Java would claim that GCJ is a better Java than Java.
Unfortunately. gcj has the potential of being much better than any JVM; faster, smaller, more flexible, more portable. It's bad for everyone that, since Sun keeps augmenting (some would say bloating) the JDK, it's nearly impossible for its developers to catch up.
Compiling "to the metal" is actually a disadvantage, since the JVM is faster than the compiled code.
This blanket statement is not true; arithmetic operations are quite faster using gcj. Object creation is however slower on my machine.
Also, you have to distribute binaries for multiple platforms, and you lose optimizations available when the JVM improves its runtime compiler.
It is actually much more versatile to distribute source and compile to the target architecture; you take advantage of the wider support in gcc. Also, you can recompile to get the new optimizations whenever the compiler is upgraded.
Frankly, I wouldn't be surprised to see MORE stuff being virtualized as just-in-time compilation becomes better and better. But I digress.
I would expect exactly the opposite: more stuff being distributed as source and compiled on the spot; witness the success of source code distributions like Gentoo, and free software in general.
Java is much, much more than cross-platform compatibility anyway.
Luckily for Sun, since cross-platform compatibility is laughable. After deciding between Java's Windows, Linux or Solaris (with Mac OS X and AIX hopefully supported by their respective vendors), take a look at the platforms supported by Python (about 20) or Perl (about 100).
It is incredibly useful, widely supported in industry, and has an array of fantastic tools to support development and deployment.
Good argument; but it's just as valid for C#, Delphi and many other proprietary offerings. The alternative value offered by gcj is the not-so-shiny freedom to modify and distribute it, which carries along a host of advantages. But I digress :)
gcj is to Sun's JDK what g++ is to AT&T's cfront.Sun yanks FreeBSD's Java license
dalibor topic
See my above comment about why I (and many compiler researchers) expect VMs and JITs to outperform "native" code in the long-run. Even from Sun's JVM is not state-of-the-art for optimization research, and the free software Java ones are even further behind. (On the other hand, Psyco for Python does very cool things, but the Python VM has many other problems, as outlined by cajal above.)Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
I really don't understand Sun's strategy. Why are the limiting binary distribution of something they give away for free (beer) anyway?
They want to control it. They do not like kaffe, gcj or some other uncontrolled surrogate to replace their implementation.
Easy!Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
Since there are already much less bloated and as good or better than SUN, Java VMs and JIT out there...
Really? Name one.
The IBM JDK is quite good. It's a little bit hard to find on the IBM website, but it is there, up to date, and I'm using it.Sun yanks FreeBSD's Java license
One possible reason why Sun is doing this is an internal conflict of Sun's internal conflict of interest?
interest problem. On the one hand, the Sun Java group wants to spread Java
far and wide. On the other hand, the Sun Solaris group wants to spread
Solaris far and wide.
Since FreeBSD is a competitor with Solaris, perhaps the Solaris people at
Sun are running a Java interference play against FreeBSD. To be sure, this
is rather illogical and suggests internal corporate chaos, but hasn't this
been the hallmark of Sun lately?
http://blackdown.org/Sun yanks FreeBSD's Java license
Then again, I can't determine if this is sun or not, though there's SunJDK and BlackdownJDK packages for linux. I can't find a solid attachment or detachment from Sun itself.Sun yanks FreeBSD's Java license
Sun yanks FreeBSD's Java license
Hmmm, it appears that there hasn't been a Kaffe release since February '04.Sun yanks FreeBSD's Java license
Yep. 1.1.5 is in preparation. Sun yanks FreeBSD's Java license
dalibor topic
IIRC, Blackdown is not a "clean-room" implementation of Java, but uses some/all of Sun's code. In which case, Sun can pull the license of them, too. In fact, since the issue seems to be that they have pulled EVERYONE'S license, so they can re-negotiate, then Blackdown's in the same boat right now.Sadly
<p>
(NB: I always thought contracts were two-way things, that pulling it like this is considered "bad faith" in a legal sense.)
Blackdown's port is built from Sun's source code. So, that won't work.Sun yanks FreeBSD's Java license
Hmm, has anyone even bothered reading the article that was referred toSun yanks FreeBSD's Java license
in the first comment before picking up the flamethrowers?
Sun yanks FreeBSD's Java license
IBM just couldn't drown it's child fast enough. After Warp4 came out with imbeded Java, IBM had to come up with a better plan for killing OS/2. So they started charging for the RUNTIME (binaries/libraries).Remember IBM Charged for Java Runtime for OS/2
GNU Classpath just had a new release. Every two months we make a developer snapshot release which gets integrated in GCJ, Kaffe and lots of other runtimes and compilers.
In other news - GNU Classpath 0.13 is out!