J2SE 5.0 Source Code Bundles Now Available
madcowbrit writes "J2SE 5.0 Source code bundles are now available
with SCSL and the new and exciting Java
Research license!
Coders have been asking for Java J2SE source code
access under new terms. The new Java Research
license gives people more access and options to
work with the Java J2SE source code."
Now I can optimize it like I do Gentoo.
Can you compile a FULLY functional JRE (not just rt.jar) and javac? If not, then this is no better than the MS source code access program. Look, but don't touch or try to do anything with it. Judging by the "SCSL Binaries - needed to complete source build", I'm guessing no.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
What is the status of SCSL and JRL with other open source licenses e.g. BSD, GPL or more restrictive. any martix?
http://www.opensource.org/
If you use the code for "Research Use" means research, evaluation, or development for the purpose of advancing knowledge, teaching, learning, or customizing the Technology or Modifications for personal use. Research Use expressly excludes use or distribution for direct or indirect commercial (including strategic) gain or advantage then you have the right to [r]eproduce, create Modifications of, and use the Technology alone, or with Modifications. That's according to the license. If they required certain classes, that's another story, but according to the license, you could change that?
"There ought to be limits to freedom"
The binaries are only fonts, sounds, and icons ... you DO get all the source code. I'm friggen impressed now!
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
Yes, you can download the J2SE 5.0 source code. But once you do, you will be bound by Sun's source code license agreements. Some companies and open source projects interpret those license agreements in such a way that you will not be able to work on projects covering anything that overlaps with functionality in the Java distribution.
I'd recommend you read Sun's licenses carefully in their entirety and think about its implications carefully before you download the source code and look at it.
Furthermore, you should carefully think about what you are getting out of agreeing to the license and what Sun is getting out of it (I find Sun's licenses inequitable).
If you want to find out how Java-like compilers and runtimes are developed and built, there are truly open source systems you might look at that don't saddle you with the kinds of restrictions Sun wants to impose on you (and they are likely better systems to learn from anyway).
7. Does this license require a click-through acceptance of terms?
... useful to me.
Yes. For enforceability, Sun requires a click-through license.
This should tell you something - only a license that plans to restrict your rights in some unpleasant way requires a clickthrough. Seriously - I always get the willies from having to clickthrough to accept anything.
14. Can I share my modifications with other researchers?
Yes, provided that the other researchers have accepted the JRL.
Cool, even my patches are subject to the license. I knew some doozy was coming that was going to restrict my usual rights. Thus the clickthrough love.
8. When do I need to get a commercial license?
This research license is only for initial research and development projects. If you decide to use your project internally for a productive use, and/or distribute your product to others, you must sign a commercial agreement and meet the java compatibility requirements.
Uhhh... so let's see, I can use the Sun JRE free for any use. I can download the SCSL Java SDK source code, and while I can't redistribute it or do other Open Source style things with it, I can at least play with it and use it for internal things if I want (I think). But I can't even do that with the Java Research License, if it consists of 'productive use'? That sounds really
So now, how long before someone builds a working J2SE 5.0 on OS X before Apple releases it ?
I was recently looking at the java source code for its threading implementation. Unfortunately, the method that specifically maps Java thread priorities to native OS thread priorities is a JNI call. In the readme for J2SE is says that such native C code isn't being distributed. Has that changed, or is this nothing more than a new licence on the existing src bundle?
Check out my podcast: DreamStation.cc Video Game Show
we can now finally get a recent java for *BSD and more obscure linux platforms (linux/alpha, linux/ppc). I don't care about support, I just want to have it more or less working.
You can find Sun's license here. Sun admits that it isn't an open source license, they are just trying to argue that it is somehow better than open source.
Because Debian is forced to classify software into open source or not, Debian has had to look at this in some detail, and they concluded that it was not open source.
If it were OSI certified then this would be interesting and very useful - however it isn't.
I think Sun is a great company but it does irk me that they are dilly dallying on open sourcing the J2SE source code. I think it's some what inevitable that they will. Hopefully they will do it while it will allow OSS and Sun to make competitive advantage of it.
...that used to be called Jalapeno that bootstrapped itself with IIRC less than 200 lines of C, just to start the process. After that, everything to do with the JVM was java itself.
I am NaN
and they've already begun working on the next version of the source code bundle, tentatively titled:
J2SE 5.0 SCB V2.0 SDK 1.5.0
or for short, J5SV2S1.5
gcc is able compile self. Does java compile itself?
Yes it does
Open Source Java Web Forum with LDAP authentication
You must be new here. hehe. Couldn't resist. Welcome to Slashdot, where you will be invariably tormented for being new. Love the username, BTW.
But, in reference to your questions,
I refer to the text:
12. Am I required to keep my research "java compatible?"
No. The license encourages you to innovate and experiment using the java technology core. It is expected that research implementations will not be compatible with the Reference Implementation from Sun. This is ok.
13. Can I publish my source code at a conference, and in white papers?
Yes, you may publish your work in the usually accepted academic manner as long as you reference the Java Research License and include the correct copyright information.
14. Can I share my modifications with other researchers?
Yes, provided that the other researchers have accepted the JRL.
15. Can I distribute binaries of my research code?
Yes. You can distribute your binaries for research purposes under a license of your choice that complies with the terms of the JRL (e.g., includes copyright notices and references the JRL).
That should give you some idea as to what good it could do and what people are expected to do with it.
Java less secure? Doubtful. It already has advantages over languages like C++ because of it's lack of pointers, and low level memory manipulation. Java-specific security issues? Also doubtful. And why would people want the source code? See above.
Hope that answers some questions. I'm not an expert, but I am learning Java and it's actually quite fun after you get into the Swing of it (really bad pun intended).
Please bother to read the article or at least follow the links in the headline. The licence you refer to is the SCSL. The article refers to a new licence, the JRL. I won't bother putting in the link because it is liseted above and anyone reading this can go and follow it as you should have done.
Be aware that sun now offers its Java source code under two licences, one of which was not ordained by the FSF an an open source licence (SCSL) and the other (JRL) which has yet to be judged (although I strongly suspect it will get on the FSF's list either).
Quoting Danese Cooper, Sun's open source diva:
h tml
.net, Microsoft, IBM, Bea, or whatever the scare-of-the-day is, that prevents Sun from licensing their code under an OSI certified license.
"IMHO (and IANAL) the JRL doesn't actually represent much of a change of terms from what the research and academic community could do under SCSL (there are some small changes around export), but it does clear away all the language in SCSL that is confusing, if you are only planning to engage in research."
from http://today.java.net/pub/a/today/2003/06/24/jrl.
On a first look, there is not much difference between the JRL and the research provisions in the SCSL. The language got a bit clearer, and a few of the most hillarious provisions have been dropped.
Research projects like JikesRVM, ORP, OVM and others seem to prefer to use GNU Classpath, rather than have their hands tied by proprietary, non-permissive licenses. I'd expect more research projects to join into the GNU Classpath pool, which is free software, in the future.
It's definitely a step ahead for Sun. Good luck on the rest of the road to freedom without fear[1].
cheers,
dalibor topic
[1] Fear of forking, incompatibility,
It is only possible to have a direct self-compiling system when the target is native code. The standard Java build process only generates native code internally and temporarily, so that isn't really possible.
As for machine-level abstraction, all of the recent x86 processors are actually RISC-style processors running optimized x86 emulators. Even RISC processors these days are run with microcode running on different and newer RISC architectures. Pretty much only microcontrollers actually implement the processor you're using in hardware.
You're totally right, that Miguel fellow should just try to come with his own VM implementation - hah, like that's going to happen! What a leech!
Switch back to Slashdot's D1 system.
It sounds like you were looking at the class library source code instead of the VM source code. It's all there; you just have to know where to look.
The SCSL is not the JRL, so your message is off-topic and misleading.
They cannot stop you from learning from what you observe, nor can they stop you from exploiting that knowledge, even for commercial advantage.
All they can ultimately do is come down against you if you actually _copied_their_code_ into a resulting work. If they try to stop you from producing something that may happen to have cosmetic similarity to their own code merely by virtue of it performing the same function, they would have to try to claim a patent over the portions of the code being copied first, which isn't the case here.
Oh... and they can also stop you from using the Java trademark.
File under 'M' for 'Manic ranting'
Stay very well clear of it:
"agreeing to this license (e.g. by downloading source covered by the SCSL) will make it impossible for you to contribute to free software clean-room implementations."
I'm certanly not going to touch it, the pre-compiled stuff will do fine.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Sun has this nasty habit of somehow getting themselves stuck in a rut with a particular major version number. For example, Solaris started on version 2.x and got all the way up to 2.6 something like 10 years later. With version 2.7, they kinda just said 'fuck it, marketing can call it Solaris 7', and they did. But to this day, "uname -a" on a Solaris 9 box says "SunOS turing 5.9 Generic_112233-05 sun4u sparc". (SunOS 5.0 was Solaris 2.0. Don't think too hard about it;-) )
I guess they decided that they were never going to release Java 2 Version 2.0, so they decided to call it Java 5.
-twb
I have yet to see a valid argument for why SUN doesnt release J2SE under an OSI complient licence.
The argument that they want to be able to use the code in their own closed things, well they can do what OpenOffice.Org does and dual licence.
There are clearly no arguments that can be made about "other peoples code", if there was anyone elses code in there, we wouldnt get to see it at all.
As for the oft-pushed argument about forking, I said it before and I will say it again.
What they need to do is to release the source code.
Plus a testsuite.
If you want to use the JAVA name on your particular binaries, those binaries must pass the testsuite.
Releasing under a string copyleft like GPL that requires all source changes to be made public would also help stop forking because anything that is used can be added to the official sun tree.
That way, anyone can use the source for whatever they like. But if you want to call something (be it modified from the SUN code or otherwise) JAVA, you have to pass the testsuite. That way, anything that has the JAVA logo on it (or whatever) is gauranteed not to be incompatible with SUNs VM.
A good cpoyleft licence would also prevent what happened with Microsoft from happening again (since any additions could be added to the SUN VM)
hopefully with some popularity the license will be revised a little
All the torrents you could want.