| |||||||||||||
|
| |||||||||||||
Sun yanks FreeBSD's Java licenseSun yanks FreeBSD's Java licensePosted Jan 10, 2005 17:31 UTC (Mon) by mmarq (guest, #2332)In reply to: Sun yanks FreeBSD's Java license by cpm Parent article: Sun yanks FreeBSD's Java license
Agreed 200%...
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#.
(Log in to post comments)
Sun yanks FreeBSD's Java license Posted Jan 10, 2005 18:47 UTC (Mon) by mrshiny (subscriber, #4266) [Link] 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.
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.
Sun yanks FreeBSD's Java license Posted Jan 10, 2005 22:36 UTC (Mon) by landley (guest, #6789) [Link] 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.
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...
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 0:14 UTC (Tue) by dang (subscriber, #310) [Link] Odd how I've never really had any trouble running Java on linux for years.
Sun yanks FreeBSD's Java license 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).
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 20:55 UTC (Tue) by error27 (subscriber, #8346) [Link] If you only run Free software then Java is a reall pain.
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.
Yeah -- no problems at all. On i386. Posted Jan 12, 2005 8:23 UTC (Wed) by smurf (subscriber, #17840) [Link] Things get worse very very fast if you dare to use amd64, or powerpc, or ...
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.
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 4:57 UTC (Tue) by cajal (guest, #4167) [Link] The only "advantage" java has over a modern interpreted language like Python is the ability to distribute closed-source binaries. 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.
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 10:20 UTC (Tue) by brianomahoney (subscriber, #6206) [Link] The simple point is that SUN cannot be trusted, it seems, to play nice in the community, and they cant have it both ways.
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.
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 20:24 UTC (Tue) by mmarq (guest, #2332) [Link] "... complex tookits doom more projects than anything else. "
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?
Sun yanks FreeBSD's Java license Posted Jan 13, 2005 9:39 UTC (Thu) by rjw (guest, #10415) [Link] Take a look at methatheme. Trying to solve the look-and-feel bit of the problem.
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 19:14 UTC (Tue) by mmarq (guest, #2332) [Link] " Compiling "to the metal" is actually a disadvantage, since the JVM is faster than the compiled code. "
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.
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 22:29 UTC (Tue) by mrshiny (subscriber, #4266) [Link] 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".
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.
Sun yanks FreeBSD's Java license Posted Jan 12, 2005 2:00 UTC (Wed) by mmarq (guest, #2332) [Link] " 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". "
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.
Sun yanks FreeBSD's Java license Posted Jan 12, 2005 8:47 UTC (Wed) by piman (subscriber, #8957) [Link] > It needs to improve dramaticly the executable native form "code" that the compiler spits.
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.
Sun yanks FreeBSD's Java license Posted Jan 12, 2005 21:39 UTC (Wed) by mmarq (guest, #2332) [Link] " 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. "
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 ??... ""
Sun yanks FreeBSD's Java license Posted Jan 12, 2005 22:44 UTC (Wed) by mmarq (guest, #2332) [Link] A late one...
" 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.
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 22:00 UTC (Tue) by man_ls (subscriber, #15091) [Link] 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. 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. 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 :)
Sun yanks FreeBSD's Java license Posted Jan 11, 2005 23:12 UTC (Tue) by robilad (guest, #27163) [Link] gcj is to Sun's JDK what g++ is to AT&T's cfront.
cheers,
Sun yanks FreeBSD's Java license Posted Jan 12, 2005 8:50 UTC (Wed) by piman (subscriber, #8957) [Link] 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.)
|
|
||||||||||||