Sun Says Java Source Already Available
mjdroner writes "In an InfoWorld article, Java CTO James Gosling says that source code for Java has been available for 10 years. Gosling claims Java is close to an open source model, though discounts Sun joining the Eclipse Foundation. He goes on to say that Eclipse's endorsement of the standard widget toolkit destroyed interoperability, saying it's based on the windows API, making it problematic to run on other platforms."
Then where is it, behind a door that says "Beware of Leopard"?
Ryan - http://www.thecosmotron.com/
So you know nothing, and need to get laid, gotcha.
http://wwws.sun.com/software/communitysource/j2se/ java2/download.html
All clear?
That's "Mr. Soulless Automaton" to you, Bub.
The situation is pretty good now, but it certainly hasn't always been like that.
Instead of saying anything rude, here is the f*cking link:
/ java2/download.html
:-)
http://wwws.sun.com/software/communitysource/j2se
That said, the license is somewhat less than free
Its partially available, on a windows system its here:
C:\Program Files\Java\jdk1.5.0_06\src.zip
Eclipse has shown that the market can indeed rally around Java optimized for Windows. Prior to SWT, remember running Together on cutting edge hardware, and the windows would still take 30 seconds to refresh? No one would tolerate the idea of running Java on Windows for Java's sake, when native apps absolutely destroyed Java apps in UI speed comparisons.
It's time for the theoretical niceties of interoperability to meet the practical demands of customer acceptance within the Windows market.
Download the JDK from java.sun.com. Unzip the download. The source code is located in src.zip. Has been for years.
That's wrong. Just download the latest JDK. 1.5 or the 1.6 beta. Then double-click on SwingSet2.jar and try the demo. It's way faster than GNOME on the Linux machines I tried it on. And at least as fast if not faster than the Windows native widget set on at least some machines. Try it yourself. It really has come a long way since the early versions which were horribly slow.
http://www.sun.com/software/communitysource/j2se/j ava2/download.xml
The article seems to have gone down before it could be mirrored, but there is an article on the same story here.
It doesn't really seem to explain WTF they think they mean, or what they've been taking. Is there somewhere where I can just download the Java source code, modify it, and distribute it, or do I need special permission and a weird license? That's not open source. If that's what they meant by their promise to open source everything, they lied.
# cat
Damn, my RAM is full of llamas.
It's improved a lot in every release, SWT or not. Today it's pretty damn good on Windows. The situation is worse on Unix though, I can agree with that. On the other hand, SWT sucks on anything but Windows anyway.
Nice.
You know where you are? You're in the $PATH, baby. You're gonna get executed!
Of course the source code is available, but you have to personnally agree to a restrictive license. This is why Sun Java is not easily available as the OpenBSD Makefile for 1.5 port shows:
That would be here under the SCSL or here under the JRL. Pick your license. For an explanation, go here. :P
Those who open their minds too far often let their brains fall out.
While I can understand Sun want to maintain control of the standard, they've got to open up the source. It sounds a little harsh considering .NET is not open at all (although MS do provide a reference version of their CLR), but it has to be done.
Sun needs every friend they can get and putting Java into every distribution of Linux is one very good way to make a lot of friends. That means opening it up. Naturally they'd be frightened of some bastardized FrankenJava appearing, but they would still maintain the standards and the trademarks and they could enforce them. Who knows, perhaps opening the source will stimulate the platform once more.
Another way of stimulating the platform is to embrace Eclipse & SWT. Sun may hate to admit it, but Swing sucks. It's a very nice and flexible API but in practice it sucks. Swing apps run with the grace and speed of a slug. Swing apps look weird even when attempting to look native. At least bundle SWT with the JRE and let people decide which to use. SWT has it's faults too, but it sure as hell transforms the UI experience of Java apps. Aside from SWT I cannot fathom why they won't embrace Eclipse. Eclipse makes Java development easy. The platform has been cursed with crappy tools (especially GUI editors) for too long and it will have to pull its socks up if it wants to compete with Visual Studio.
It *IS* available if you work for Sun.
...it's Cocoa! : D
(burn, karma, burn!)
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Yeah, the Java source to the class libraries ... sans the C source to all of the native stuff and the source for the JVM.
Is the licensing still restrictive? If that is the case, it doesn't really matter for most of us.
Good luck finding the license on that page without having to register first.
I enjoy scrolling up and down 15,000 line source code files as much as the next guy. That's why it's so much fun to look at the GCC sources.
/.'d at the moment.
Occasionally, it's actually useful to see how someone implemented something, for educational purposes.
But can I modify it, make it work on my new OS and processor and sell it without paying royalties? Maybe, distribute it under the GPL so it can come with FOS OS' in a truly free sense?
Having source code isn't everything. Back in the old days, there was always source code for everything; UNIX on any of twelve or so different platforms wasn't binary compatible, but source compatible. So if you wanted to make a program and sell it, like PeachTree (yeah it's that old), you HAD to distribute the source code. Otherwise, you'd either have to distribute dozens of different binaries or stick with a single platform, which wasn't profitable.
It was copyright infringement to make money by changing the code and selling it... and you couldn't give any of it away to someone who didn't have a license to it. And even if you did make modifications, you couldn't use them when the next release came out unless you ported them over each time.
There's a difference between something being OpenSource and just having the source. Even if it's a free product like Java.
What can you legally do with it? What separates it from being truly open source? I'd read the article, but it seems
The src is out in the open alright, but it's still under a proprietary license, so you'd better stay the hell away if you're ever likely to work on something similar. *Insert rant about how the term Free Software is better than open source here*. When we used Digital Unix at work many years ago, we had source code access, but that still didn't make it free in any sense.
Swing is a joke. It doesn't look native, it is a resource hog
1995 called. They want your complaints back.
You know, back when Java first debuted, its critics complained that it ran too slow. This was back when everyone was running 486 DX/100's, and Pentium 75's were just coming onto the market. Advocates of Java countered that hardware would soon be fast enough to render Java's slight speed disadvantage (due to being interpreted code) irrelevant. Plus, a JIT compiler was in the works to make Java run just as fast as native code.
Guess what? They were right. We're not running 100 MHz machines anymore. We're running 2.4 GHz machines, and Java is just as quick and responsive as any other app. Today's machines have way more than enough CPU power and memory capacity to run even the largest Java apps with no delays at all.
Time for you to come up with some new, fresh complaints.
Like woodworking? Build your own picture frames.
At least on my machine under Linux, Swing is definitely faster than SWT. Sounds almost absurd, but is true. I did a search some time ago and found posts claiming that IBM's official positions was that they were not interested in improving the speed of SWT-GTK. They can kiss my a** then :-)
SWT-FOX (http://swtfox.sourceforge.net/) looks like a good idea and is supposed to be faster, but I have never been able to get it to work satisfactory (font problems, crashes). AFAIK, it is being maintained by a single person in his free time. Perhaps RedHat or Novel should support the project.
Don't get me started on SWT anyway - I think the design is terrible; it looks like a somewhat cleaner port of MFC.
I do agree that the Motif version looks like ass (and is a pain to use), but then, that's Motif's fault, not SWT.
This is great news, I always wanted to remove that pesky garbage collector....
Sorry, but this appears to be FUD. If you want a native look and feel you need to put in one line of code to tell the UIManager to use it. A few more lines can give the user control of the L&F.
.NOT I don't really believe this and I don't see how it would matter very much if its true. Modern OO languages all offer a similar set of basic features and it's no more suprising to find generics in Java or .NET than in C++.
Once a Swing application is up and running it's not noticeably slower or less responsive than any other GUI application, assuming its been correctly written, and it will work cross-platform with no changes. I've taken desktop applications from Windows -> Linux -> Solaris -> HPUX with no porting effort.
As for Java 5.0 features being forced by
Ame
Just a second. I know the Java sources have been available for a long time in src.zip. I've consulted it many-a-time. But what about the native code? You know, the actual runtime itself, and all the C code that goes behind all those "native" methods in the Java runtime? Is that code available now too? That's the code you'd really need access to in order to port the JRE to a new platform.
Like woodworking? Build your own picture frames.
Particularly:
So is Skerrett being disengenous when he says that and, if he is, is he just getting back at Gosling for over simplifying?
Somehow I really doubt that Gosling doesn't understand how Eclipse works in the context and I doubt that Skerrett is dumb enough to think that he does, though I'm less sure of the second point as I don't know anything about him.
You can make an argument that SWT leveraging OS-specific APIs is a strength, although I don't really like Eclipse under GTK (need to try it with Motif), but I would have preferred it if he had just rebutted the point directly without stooping to slurs.
Actually, I have no earthly idea where I got these expectations all of a sudden. It's like I relapsed into freshman naiveté. "All debates should be logical and factual. Then the Internet will be one big Web of Peace."
Rome wasn't bilked in a day.
You can get the native c code for the vm and such from here: http://java.sun.com/j2se/1.5.0/scsl/README-SCSL.ht ml
"It's been there for years," Sun CTO Ned Baker replied, "just grep your /java/bin directory for the string 'malloc(all);' and you'll find it."
"Made up/misattributed quote that makes me look smart. I am on
IDEA is also a lot better than Eclipse functionality-wise but that's not really releveant for this comparison.
Java is great. Java is fast. I agree with your post.
That doesn't mean that SWING is not slow and bloated.
Ive used Java apps with SWT and OpenGL that work great.
I have yet to see or use a SWING app that behaves decently.
Advocates of Java countered that hardware would soon be fast enough to render Java's slight speed disadvantage (due to being interpreted code) irrelevant. Plus, a JIT compiler was in the works to make Java run just as fast as native code.
Just to clarify, Sun originally released Java 1.0 as a "reference" copy for other JVM vendors to test against when developing their own JVMs. As a result, it was lacking a JIT and thus was incredibly slow. That slowness disappeared in Sun Java 1.1 when Sun realized their mistake and began bundling a JIT. At that point in time, Java was still slower but not to any massive degree.
Sun's development of the HotSpot mixed-mode JVM finally put the performance matters to rest. HotSpot executes real-world code at amazing speeds, sometimes outdoing native code. The only problem is that it isn't optimized for short-lived programs, thus making microbenchmarking absolutely useless. (Not that it has been all that useful anyway. Modern CPUs and Operating Systems do all kinds of tricky trickery to make real-world programs execute faster than micro-benchmarking. Now if only we could get that through people's heads.)
Javascript + Nintendo DSi = DSiCade
Ah! A fellow Java developer!
Did Sun fix the bug where resizing or clicking a JTable column header while editing a cell loses the data?
>We're running 2.4 GHz machines, and Java is just as quick and responsive
>as any other app.
Do you ever regularly use Java applications? I have the impression you don't, or you wouldn't state such a plainly wrong fact.
At least on Windows (argubly by far the most important platform), as soon as there is some load, Java applications' GUI reponds MUCH slower than any native application.
I don't even think this is Java itself being slow, but the Windows kernel giving higher priority to threads that deal with UI elements. Since Java is not having a native GUI with Swing, it can't get the same treatment.
It's quite easy to test: just start something which puts heavy load on the system, then try to use a Java application. It's not hard to see where the "Swing is slow" idea comes from!
This is not a link to the source. This is not even a link to the license, as I suspected sat first. Got any better?
Using themes doesn't work that great with Swing either (Not Swing themes but Gnome, KDE, Windows global themes). Swing apps will stick out like a sore thumb.
Eclipse is running pretty well on the ubuntu 5.10 I must say. I've installed the Sun JDK 1.5 (that's the version we developers still use :) and the latest Eclipse version. I've seen some small idiosyncrasies with GNU classpath, but even that run pretty well. One should not use the default version of Eclipse. Since the installation normally consists of unzipping and running the eclipse binary, you are advised to use the latest version anyway. And I must admit that previous versions were way less responsive. It's still less responsive than Eclipse under Windows, but it definatly is workable.
SWT is far from perfect. It's definately more a hack than Swing, which is setup very neatly. But it does not matter, it's pretty smooth, has very nice widgets and always uses the underlying platform L&F. The Swing default is the Sun look and feel, which is beautifull, but not something I want. On most applications you cannot set the L&F yourself, and the developers choose either Swing L&F, the platform L&F or even worse, AWT. As long as the Swing applications are not in agreement *themselves* and as long as Sun does not make the platform L&F the default, Swing is doomed.
Anyone who has actually made the effort to look at Swing in the past year knows it has come a long way. It looks fine, runs nice and fast and is quite robust. Download NetBeans and check it out.
Ummm...that error message just says you need to download the source code in order to build it.
The "restrictive license" you refer to allows you to make any changes you want to the source, but to call your code "Java" it has to pass Java certification. This is to enable the "write once, run anywhere" capabilities of Java.
Java is not the Java Development Kit, or any other specific peice of software. To Sun, "Java" is a trademark, so they can't even use it as a noun. But the rest of us can get by with thinking of Java as a collection of specifications: the Java language, the Java class libraries, and the Java VM spec. None of these is software — software can only be a implementation of Java.
That might seem like a silly distinction, until you remember that Sun is not the only vendor for Java implementations. Not only are there commercial implementations, but there are open source implementations of all three, specs. Of course, these all lag way behind commercial implementations, as open source clones are wont to do.
Anyway, when people say "Sun should open-source Java" what they really mean is "Sun should open-source their implementation of Java."
Which brings us to:
"Open source" is not software where the source code is freely available. It software where you can obtain the source code provided you agree to a license. That license specifies that you must make any changes to that source code available to anybody else who agrees to the same license.
And here's a non-legal issue: if you're serious about making your product open-source, you don't just throw the source code over the wall and say "go crazy!" You make a serious attempt to fold contributed code back into your main source tree. That's a serious administrative cost, and a big reason so many companies are unwilling to OS their products.
In java, you add a method to reorg the data and redisplay. just like RealBasic!
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
How open does Java licensing need to be?
Answer: Open enough that the most important Linux distributions will include Java.
It is correct that Java is close to being FOSS, but that makes it even more the pity that Sun could not make the few adjustments needed to attain this goal.
Sun should by now be over the trauma of Microsoft attempting to hijack Java and accept things like SWT as the kind of sideshow that the Ubuntu/Kubuntu thing is.
I wrote parts of this stuff
You do need to "register" with Sun to get the source, but same goes even for New York Times... The registration is free.
In Soviet Washington the swamp drains you.
Although Sun has been generous with their source and created great opportunities for clever developers, Java has generated the need for a new cross platform OO language. The decision to implement generisity using type erasure has irrepairably damaged the run-ime integrity of the language. This will become more and more apparent as people become better aquanted with the new specification. Hopefully the open source community will build on the experience gained through working with Java to create a new truly type safe cross-platform OO language. If not... all hail .NET chime... chime... rattle.
Anyhow, all you have to do is to set the system propery swing.defaultlaf to the L&F manager that you want to use. If you want to force the Windows L&F for example, use the following:
(ignore the stupid space that is added to the above line)You can read all the details, along with the class names to use for other look and feels at the Java tutorial page.
that was true at the time of java 1.1 or nowadays with a very beginner programmer. any application using swing (using the current OS look and feel) behaves in a very similar speed as a delphi app. if u can make a good optimized assembly code, good, but that is not what the market wants. The market wants "developer performance" (speed in the coding process),interoperability and application performance in this order.
Amen to that. We use a Java-based revision control application here. Compiled to native code, according to the installer. Slower than rocks on my P4 2.8 GHz box. Azureus on my 1.25 GHz G4 under Mac OS X is even worse.
It's different now, of course and even external people have noproblem downloading it. That's good since I don't work there anymore. :-)
Sorry, but this appears to be FUD. If you want a native look and feel you need to put in one line of code to tell the UIManager to use it. A few more lines can give the user control of the L&F.
Once a Swing application is up and running it's not noticeably slower or less responsive than any other GUI application, assuming its been correctly written, and it will work cross-platform with no changes. I've taken desktop applications from Windows -> Linux -> Solaris -> HPUX with no porting effort.
This is simply not true. I have never seen a Swing app look or feel native on any platform under Java 5. On Windows fonts look terrible and on the Mac you do not get the standard menus and it is more than common to have incorrectly named items. Under Java 6, on Windows, Swing looks dramatically better but its still not quite right, and certainly doesn't feel like a Windows app.
SWT, although far from perfect, is a massive improvement over the mediocrity of Swing. It tries to bring the native look and feel to Java applications and succeeds with varying success, depending on platform. SWT has learned from the mistakes of Swing: no one API can provide a good cross-platform solution.
It is my belief that Swing is the primary reason for lacklustre adoption of Java on the desktop. Nobody actually wants to use applications written to it and so very few people write them. In fact I would go as far to say that Swing is the primary reason for the massive adoption of .NET. Windows Forms may not be cross-platform but it looks and feels native.
Yes, Java is opensource.
In fact you can get the source code, if you accept to sign a licence restricting you to distribute a modified version or reuse the code elsewhere.
So basicaly: the source is availabile (it's opensource) but not reusable freely (it's not free software).
Sun executives often do this confusion when interpreting the F/OSS calls for a free java.
Meanwhile, linux distributors don't make the same mistake: that's why (java being considered non-free) you won't find the Sun jdk/jre in the redistributed medias of Debian, Fedora Core, OpenSuse or Ubuntu (and *BSD, even).
Just create yourself an account, sign in and then follow the links. Believe me I have downloaded the code before, so it is possible.
Jumpstart the tartan drive.
Somebody! Please over there at Sun!!! Do not give that grass to Gosling "The Father of Java" anymore!!!! Or my heart would definitely break.
"Java is already open source for 10 years" and "Eclipse destroyed interoperability" is... *NO* *COMMENTS*.
Sun for last ten years - and 6 versions of Java - jumped from one application field to another. Sun's lack of the focus - and Gosling sayings confirm that lack - is sole reason for the problems of Java. Companies just can't trust Sun at that point. (*)
Eclipse claims are just plainly laughable. And in fact one of the most spoken problems of Java and Sun's control over Java. Since Java slowly moved to server side of computing, Sun payed less and less attention to the one simple thing - GUI. There is no standard Java GUI API. Period. People tried what is shipped with Java SDK - AWT & Swing - shivered and moved on. Plainly unusable. In fact, I do not know single successful Java GUI application which uses Java's native GUI toolkits. Eclipse foundation just did what it had to - filled the gap. Now we have GUI toolkit. Which is quite performant, usable on Windows/Linux/BSD/Mac. And people are pretty happy about it. Even me. And many applications already use it (Azureus as an example pops up in my head). Check the http://www.eclipse.org/swt/community.php for more.
P.S. Original article includes the pointer that Sun's planing to try assault on embedded space again. Good Luck Gosling. You freaking need it.
(*) My company wanted to standartize of Java, but backed off the plans. Middle management wanted Java for its stable and rich development environment. R&D manager flat out refused since Java is in fact closed source and there is no sence in adding another dependency to the already huge software package we have. And nobody can assure us what Sun will do tommorow - what if they drop support for M$ Windows?? There is *no* competing Java implementations. And there is no standard for Java.
All hope abandon ye who enter here.
Performance isn't the only issue. Appearance and behaviour are too. When Microsoft ships a new verion of their common controls DLL, will my Java app change? Will a Java app today fit-in on NT7 as well as a native Windows app will? When I make global configuration changes to my Windows environment, will my Java app reflect those changes? This has been one of the biggest problems with Java over the years. It's like GTK apps such as GIMP or Ethereal that have their own diabolical (and unusable IMHO) file open and save dialogs, when it could have just been delegated to the OS and done it properly and in a user-friendly manner. When things are uncomfortable to use, people don't use them.
To save you the trouble, here are some screenshots
of JDK 1.6 (mustang) running on Linux under GTK. Notice how Swing
adapts to the user's desktop theme.
Expert Java EE Consulting
When Java 6 is released, Swing will use native drawing on all supported platforms. This means under Linux, your swing apps will blend right into your gnome desktop (at least as much as SWT anyway) and on Windows I doubt any user could now distinguish a Swing app from a native app. Sun has put a lot of energy into making Swing fast and good-looking, now that the supporting Java class framework is mature.
In fact, with Java 6 it is hard to find any compelling reason at all to build SWT apps instead of just using Swing. SWT apps are not portable without bundling specific dlls for each platform. Further SWT isn't even that great of a framework, but it has worked well for what it was made for, eclipse.
So please stop spouting this continued FUD about how bad swing is. Yes it was horrible in the past and looked like the ugly step-child. But with Java 6 Swing is poised to be a good candidate for serious desktop java use. Even a couple of years ago, Apple's customizations to Swing illustrate that Swing was capable of being a first-class GUI citizen. Apple bundles a number of Java apps that are wrapped in a nice app bundle and no one would ever know there were Java rather than some native binary.
The parent is a troll (possibly an IBM troll).
Sun paid tons of money and spent years writing the class libraries. Why should they give their work away for free? They license this code to IBM, Oracle and BAE for a significant sum. Why should they give up this revenue?
Sun has changed the licensing for the JRE to allow it to more easily be integrated into Linux distros. The parent is either ignorant of that fact or deliberately omitting it.
Sun is less likely to maintain to maintain the standard if they open source the code. What kind of ass backasswards reasoning is this?
Why embrace SWT? This is IBM's attempt to bastardize the JDK. What's more, it's not pure Java. For instance, when I bought my Intel iMac, NetBeans 5.0(pure Java Swing) worked immediately, whereas an SWT library needed to be replaced for Eclipse. Why should Sun integrate a less than fully platform independent competitor's attempt to break a standard?
See this blog for more analysis on SWT vs Swing:
http://www.javalobby.org/java/forums/t18544.html
The jury is out on whether SWT is technically superior to Swing.
If you think Eclipse makes Java development easy, you obviously haven't used NetBeans 5.0, which is significantly superior to Eclipse in every way. It includes functionality out of the box (JSP compilation) that you need to pay for (MyEclipse) with Eclipse.
You obviously have an IBM bias with the following stated positions:
1) Open Source Java so IBM doesn't have to license class library source from Sun.
2) SWT should be included in JDK, thus polluting the standard.
3) Eclipse is the best IDE and makes developing Java "easy", with no mention whatsoever of the clearly superior NetBeans 5.0, or, for that matter, IntelliJ.
This space left intentionally blank.
Ummm...that error message just says you need to download the source code in order to build it.
It says that because you have to do that because they can't download java automatically for you or bundle it because you have to agree to a restrictive license.
The "restrictive license" you refer to allows you to make any changes you want to the source
And to not distribute it. In fact, you can only use the source code for "research and development". Even internal use isn't allowed. Let alone distribution. And you can't download the code if you're from certain countries. But if you modify it, guess who gets to use your code for free, and distribute it?
SCO employee? Check out the bounty
only counts in horseshoes and hand grenades, and if I'd wanted to hear from an asshole I would have farted.
All softwares has license oneway or another. Click on accept or not, you have to accept the license to use the software (binary or source). If someone call Java license is propriatary, then I think GPL is not only propriatary to one developers, but millions developers out there.
I cannot sell GPL software, cannot include it in my own software. So, go with the comparison.
For those think I am trolling, here are some reasons:
1) You cannot sell GPL software, you can only charge for distribution of it.
2) You cannot include it in my own software, unless I make my own software GPL, which either means
a) For those think GPL is non-proprietary: it's no longer "mine" in a sense that anyone can take it, change it, and charge for it, or
b) I donot make it open source and distribute it and violate GPL, which means GPL has millions of strings from every developers out there who put work into it. or
c) I cannot redistribute my software, which means my work is only useful for me. What a waste most of time, and poor economic model.
src.zip doesn't have the sources to the sun.* packages, which contain classes that are not part of the API.
UIManager.setLookAndFeel(UIManager.getSystemLookAn dFeelClassName());
There you go. Now it matches your system UI.
If you were talking about JVM's there are "competing implementations" please see http://en.wikipedia.org/wiki/List_of_Java_virtual
And perhaps when you were speaking of 'no standard for Java' you forgot to look into http://en.wikipedia.org/wiki/Java_Community_Proce
I have also downloaded the source before (even back when my country was in Sun's "terrorist" list). The point is that Java's source is not available enough if one cannot even give a direct link to the download. And we are not speaking of freeness or openness here, just availability.
These issues are fixed in Java 1.6 (Mustang), due out Real Soon Now.
ZFS: because love is never having to say fsck
Why no Obj-C love man?? ;)
"Personal ownership is a hallmark of conservative capitalism. And I don't believe I am entitled to anything that I did n
Don't be stupid. I've looked through my dictionary, and I cannot find the defintion of "available" that states "must have a direct link". Stop being so fscking pedantic. The source is there, it is available, and it is available to everyone. You just have to register. The registration is free. You don't even have to use your real name or address.
To repeat, THE SOURCE IS AVAILABLE!
A Government Is a Body of People, Usually Notably Ungoverned
The point is that Java's source is not available enough if one cannot even give a direct link to the download.
By that measure, articles from the NYT are not available enough either, you need to register with them as well.. same for many others. Let me just point out that you have a very weird idea of what 'available' means.
The consequence of the way in which the source is available (specifically the licence) is that you cannot share it with friends, mirror it, or otherwise distribute it without SUN's prior explicit permission.
That however has to do with freedom and all those other things you did not want to mention. Available however it is, and has been for years.
Well, 'String[] args' has always worked for me in Java.
Jumpstart the tartan drive.
And to not distribute it. In fact, you can only use the source code for "research and development". Even internal use isn't allowed. Let alone distribution.
This is simply not true. You're allowed to make any changes you want to the source and redistrubute it under the JRL to anyone who accepts the terms of the JRL. You can publish your changes in whitepapers and share them with colleages.
What you can't do is claim your changes are Java. And there's a very good reason for this. Java implementations need to be compatable with other Java implementations.
If you change the source to Java and I want to use your changes, there's no problem with that. But that fact of the matter is I'm probably not going to want to use a hacked, incompatable version of Java that someone is trying to pass off as the real thing. Requiring such hacks to be clearly labeled under the JRL protects me from such things. If you want your changes to be called Java, you have to get them certified as Java.
hahahahahahahahaha
That's pretty good.
1960 called, they wanted to remind you about big O notation, and how throwing raw power at something algorithmically shitty won't help much.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Eclipse isn't slow because it's SWT (on windows, anyway). SWT is often much faster than Swing on Windows. I've written front ends in both. With XSWT, it's also a ton faster to write as well.
Eclipse is slow because everything is implemented as a plug-in. It's the flexible architecture that IDEA doesn't have that makes it slow (and often unintuitive).
it's 2006 and they still can't track the font used by the rest of the desktop?
swing is ugly as hell...
Hmm, if you're saying Swing is algorithmically more complex than a native UI, you better have something to back it up with. I have a hard time seeing why this should automatically be the case for a framework that is responsible for drawing an UI.
Beware: In C++, your friends can see your privates!
"UNIX on any of twelve or so different platforms wasn't binary compatible"
With all due respect, that's pure utter rubbish. ATT System V UNIX for the 386 PC's WERE binary compatible. This was distributed, and modified, by Microport, ESIX, Bell Tech, and others. And it was put on different types of platforms, not just the IBM PC (Cubix was one, Intel's Tahoe box was another; and there were others whose name I forget).
They were ALL binary compatible. People could, and did, run the same applications on different i386 platforms. The changes were kept to the kernel level, and were mostly driver changes. But at the user level, the libraries and binaries were all compatible.
Anything which deviated from ATT's standard wouldn't work. But then, according to ATT, you couldn't call that UNIX.
This is just plain wrong. I can smell Java apps from a mile away.
I have seen Java apps that were quick and responsive (Jbuilder comes to mind). What voodoo was used to accomplish the feat I don't know, but the vast majority of them are sloooow and suffer window refresh problems. Just because a machine is 24 times faster just means that instead of throwing the monitor through a wall, I just want to put my fist through it. What does it say about the quality of a language if it is so inefficient that it needs super powerful machines to run its programs? If Java had some amazing additional features that gave it dramatically innovative capabilities or made it far easier to use, I would say its worth the tradeoff. However, it does not, and hence C++ is still what most desktop apps are written in. Smart pointers alleviate many of the problems usually associated with C/C++ programming.
When someone solves the old, stagnant problems, I will come up with some fresh new complaints, or probably praise.
MVC
Swing pretty much forces you to use it whether it's appropriate or not.
You are right that Swing should track the appearance of the desktop. You are wrong that Microsoft does it. Controls look different in .NET 2 vs say apps written in Visual c++ 4. Now that might be because the code is linked static but its still a problem. Microsoft hasn't drastically changed their interface since Windows 95, but if you remember running 3.1 apps on it they looked like shit too. Likewise, Carbon apps sometimes look odd in OSX. Also, using windowmaker with gtk apps or kde with gtk apps can be odd still. There are newer x11 standards to help with these problems, but i just wanted to point out no one has it down perfect yet. Its a great goal though.
.NET or in a subset of supported platforms. FreeBSD licensed java and now no other bsd can do it. (sun's fault)
Behavior is a bigger problem. You notice this on OSX running java apps more than any other platform. In fact, SWT doesn't work right in OSX. Don't blame apple, they just ported sun's java implementation and tried to fix the problems you mentioned. What burns me is that sun doesn't have cross platform media libraries to do graphic manipulations and other things you can do in
Overall, sun needs to be more open to certifying java jdks on more platforms. This effects linux people to presuming you don't run on x86 or amd64/emt64. What if you run linux on a sparc or powerpc? What if you want to run embedded? Write several times, run in a few places. (that should be sun's new slogan)
Please someone write a portable, cross platform, object oriented language/runtime with a decent graphical toolkit and useful libraries. Nothing comes close. java implementations can't run everywhere and there are problems. Other implementations like Mono don't work right on most operating systems. (mono runs on windows, linux and partially on OSX and solaris but does not work right on *BSD or anything else i can think of)
MidnightBSD: The BSD for Everyone
I have no problems with SWT-using apps like Eclipse and Azureus on GNU/Linux for either x86 or x86-64.
I remember, about 10 years ago, when they started to allow people to download the source. It was all very exciting. I downloaded it and made a futile attempt to build it on UnixWare. The build environment from what I recall is atrocious. So anyway, I've always been like "wtf" when I hear stories about opening up Java source, wondering if the whole thing was just a dream.
As an everyday user of Swing apps (and specifically jEdit) I assure you that under Java 5 Swing apps *do* look native enough. I have to strain my eye to find very slight differences. Note that many native win32 apps alter their look and feel uch more, "to stand out", probably. Opera on win32 looks less "native" than most Java apps, and newer MSO apps always keep going for some new and rather alien (though cool) look and feel.
Computers make very fast, very accurate mistakes
Not quite so clear.
It's under a license that's not really an Open Source or Free license. The same goes for things like the Java Media Framework- something that could be useful and allow some rather nifty VoIP applications, etc. but is languishing because Sun's the only one that can legally extend it.
Yes, the source is available, but few, if any can really honestly USE it like one can with Linux, GCC, etc.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
What language is it written in ? Thanks.
Thanks for trying, but as it's already been pointed out, open source licenses don't tend to place any restrictions on obtaining or using the code. You need only to agree to the license in order to redistribute.
The GPL goes so far as to explicitly state as much.
Anyhow, on to your main point, I think most people around here believe that having a complete, open source implementation of the latest version of the Java specs would be extremely beneficial to Java and the Java community as a whole. So, we can't quite understand why Sun is engaging in stupid double-talk instead of trying in earnest to make that happen. Obviously, the easiest way would be to open source their existing implementation.
The oft-stated idea that Sun's refusal to contribute is somehow protecting "write once, run anywhere" is simply ridiculous. First of all, that whole notion is pure fiction because new APIs are always being added to the platform. Any code that exploits a new API won't run on an older runtime. And now, with Java 5.0, it's even worse, as, by default, javac produces bytecode that won't run on a 1.4 JVM, regardless of what platform APIs are used.
Meanwhile, because of the Sun's license terms, most Linux distributions are forced to pick up various open source implementations, none of which are not complete. Instead of getting help from the distributions in solving the problem of Java platform version dependencies, Sun has forced them to make whole situation much, much worse. Write once, cross your fingers, and hope for the best!
Trying to install and run Java applications ranges from a pain to a nightmare on every single platform. But, really, there's no good reason that I shouldn't be able to launch a Java application as easily as a native binary. Sun can't solve this problem themselves, but they do have the power to take away the roadblocks preventing it from being solved for them.
Running all your code in an emulator for a platform that doesn't exist... Yeah that sound like a great idea!
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Does writing apps using the Cocoa windowing toolkit provide any substantial performance boost over SWT by chance? I'm seriously ignorant on the topic, and I only ask because it seems from my perspective that the Azureus Bit Torrent client on Mac OS X is a resource hog, not to mention very sluggish in launching. I would say the user interface is even somewhat unresponsive. I believe this application uses SWT, but I could be mistaken. Are Java apps in general just this way on Mac OS X, or are there benefits to be had by switching to a Cocoa Java implementation? Thanks.
Running all your code in an emulator for a platform that doesn't exist... Yeah that sound like a great idea!
It isn't usually a great idea, which is why Java on most computers doesn't do it. On most machines the byte code for the imagined platform is merely a transitional stage before profiling and translation to native code. Sometimes though, it is a great idea. This is because Java byte code is smaller than much native code. So, in low memory situations (such as in memory-limited devices) running java byte code on a JVM is a space-saver.
according to the BCL you have no right to modify the files in the JRE and/or the JDK. Doing so automatically terminates your license for the JRE from Sun.
cheers,
dalibor topic
I'm a big Eclipse fan. I use it daily. I love it.
However, there are definitely little niggling problems based on it's close relationship with Windows. For example, the Windows clipboard is synchronous, therefore the SWT clipboard is synchronous. The X clipboard is asynchronous, which has caused lock up problems in the past (not present currently). There was a time when you couldn't have ':' in a filename because of the windowisms built in to handle window drive letters. Additionally, since the Eclipse folks seem to think that printing is a function of your widget set, there is still no printing for Eclipse on Linux (since GTK doesn't yet provide printing support).
So are non-Windows users slightly second class Eclipse citizens? Yes, but not by much, and to be honest, I generally don't notice it at all. Eclipse feels just as good to me on Linux as on Windows.
Heh. Of course, the Java bridge is now deprecated (with good reason; Java's lack of dynamism causes large impedence mismatches with ObjC). I'm hoping Apple officially adopts PyObjC as a replacement.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Yah. I've picked my license, which is why when I *DO* use java, it dialect I use is gcj. That's a license I can live with.
That said, the gcj libraries are so incomplete that I normally don't use Java at all, but use something else instead. (Just what depends on the project.)
I think we've pushed this "anyone can grow up to be president" thing too far.
The imitation file chooser seems to just accept a nonexistent file name when you press enter, instead of giving an error and letting you make your correction. Odd behaviour. It also doesn't let you sort by modified time in the detailed file listing. Thanks for nothing, you bastards.
Look at the java bug forums: Many of Swing's detractors people who actually develop apps with it and want it to succeed.
Thar she blows !
Freedom is strength, Ignorance is peace, War is slavery.
From my experience, you can't tell wether a Cocoa app is written in Objective C or Java (except in launch time), so there's definitely a difference to SWT.
What he meant was *some* source to *something* was available. For example, where's the source to the binary module that implements Adler32? What? Java has binary code linked into it? And yes, I'm still waiting for a complete/official specification of what Java and the JVM actually is. Come to think of it, I've been waiting 10 years.
Try IntelliJ IDEA.
just my blog and pix
Java developers, meanwhile, want to preserve interoperability and reliability, which is maintained by the current rules governing Java, Gosling said. To be certified as Java-compliant, software most undergo a test suite.
"They really like the fact that we're very compulsive about the whole testing thing," Gosling said.
Exactly. I think that the people calling for Java to be open sourced don't get the concept. Honestly, I think they must all be either people who are against java just because they have a platform they prefer (A very common occurrence among engineers) or they are trying to destroy the advantages of Java (Simplicity, slow and deeply considered addition of new features, compatibility) in order to make it easier to sell a competing product.
The fact is, nothing will be gained from open-sourcing Java that you can't get by evolving the existing license (for instance, sun is modifying it to be able to ship the JDK with other products). On the other hand, much will be lost. Sun has been a creator and beneficial guardian of this language, and has crafted it into something that many users just love.
Now, many people don't need Java. For instance, if you are making a smallish website, you are just stupid if you try to use java--use ROR or
However, if you have a project with an architect, a handful of software engineers and dozens of programmers working on a huge code base at the same time I don't think you can pick a better platform.
If you are not in java's target audience, please SHUT THE HELL UP about it having to be open source. You don't have to feel bad about java not being appropriate for you! I give you permission to go use a scripting type of tool and solve your problem much quicker, but don't try to mold my favorite tool into something that fits your job just because it has a cool name and you think you should be using it because everyone else is.
Those of us who really need java like it pretty much as it is--slow intelligent improvements, fewer terse, confusing or overloaded language features and a large number of users more interested in making readable/reusable code (as opposed to the users who just want to get the job done with write-once code). Overall it's just a good, solid, readable language, leave it at that.
You have got to be kidding.
You are saying a 150 meg JVM is somehow smaller than C code that can run on machines with a few kilobytes of ram?
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Like many things Sun does with Java technology licensing, it sorta sounds good in theory, but it's next to useless in practice.
x t
In practice, it is impossible to know if anyone else but you has accepted the JRL, unless you look over their shoulders and see them clicking on it. So putting your code on a web page without click-through is right out of question. Putting your code on a conference CD: out of the question. As a JRL-bound researcher, you need to actively enforce Sun's licensing regime on your peers, and there is nothing researchers love more than to spend their time on Sun's legalese.
Analogously, while you can in theory publish papers on the code, you may need good lawyers to check your paper submission, since Sun never says just how much quoting in a paper is OK. Your submission, if it describes interna of Sun's implementation, to compare your own better implementation against it, can be particularly interesting for your lawyers, since Sun claims that their source code is a trade secret, for example in the Mustang beta license:
"Licensee agrees
that Licensed Software contains Sun trade secrets."
at http://java.sun.com/javase/6/jdk-6-beta-license.t
Oh, it looks like in Sun's tradition of silent license changes they have changed that recently to say:
"3.2 Licensed Software is "Confidential Information".
Licensee may not disclose or use Confidential
Information, except for the purposes specified in this
Agreement. "
which means the same thing.
cheers,
dalibor topic
You have got to be kidding.
No.
You are saying a 150 meg JVM is somehow smaller than C code that can run on machines with a few kilobytes of ram?
JVMs aren't that big. Almost all new mobile phones have JVMs in, and they are memory limited devices. The J2ME system (Java Micro Edition) typically used in such phones requires only a few 100k for the entire Java system. There is even a J2ME implementation that includes a run-time profiler and native code generator that will fit in under 1MB.
But anyway, if you read what I posted, I was not talking about the size of the JVM. I was talking about the size of java byte code - the code than runs on the JVM. This byte code is compact, which is why it is increasingly favoured for low-memory embedded systems.
I don't know about using Swing to build a really resource-intensive application, but for simple data visualization apps, it works just fine. I have written a couple of data visualization apps where you drag a cursor over a drawing and things drag/compute/update, and I have not complaints about the quality of the graphics and the speed of the updates. I can't see writing the type of in-house apps in VB anymore. The one big hangup is the layout manager. It takes some learning curve to understand what it is all about, it takes more learning curve to know how to do layout in NetBeans because the layout is not like VB and will confuse the heck out of you (although the new NetBeans has this new flow layout thingy, I am sticking to the conventional layouts for max portability), and layout takes an awful lot of fiddling to get what you want. Swing may not be the fastest, but it is fast enough for my lab data visualization apps, and it is portable to Windows/Linux/OS X as well.
Sun paid tons of money and spent years writing the class libraries. Why should they give their work away for free?
...which is significantly superior to Eclipse in every way.
They're under no obligation to, no doubt. But neither was IBM under any obligation to release the code for SWT, Eclipse, Derby and others. IBM has stepped up and released code under an open source license. As a programmer, I like working in Java far more than I do working in C#. For that reason, I want Java to become as ubiquitous as possible. Opening up the source would go a long way towards making that happen.
Why embrace SWT? This is IBM's attempt to bastardize the JDK.
Bzzt. Wrong. SWT was created in response to criticisms of Swing and AWT on the part of developers. Developers wanted an API that was easy enough to use and made their apps look native. AWT failed the first part, and if Swing ever does meet the second criteria, it will be because SWT pushed it to do so. And if you don't like working in SWT, try JFace. It is designed to be developer friendly and is, IMHO, much easier to develop in than Swing.
SWT was originally written long before Swing or AWT were anything but laughable. If you're going to bash SWT, do it on its merits (there are some), but to claim that IBM was trying to do anything besides solving a serious problem for developers just isn't true.
What's more, it's not pure Java.
So is AWT. It's included in the JRE. If SWT were included in the JRE, developers wouldn't have to care that it isn't pure Java.
Like the way that Eclipse had support for Java 5 language changes almost a year before NetBeans? For a company that is steering the direction of the language spec, that's pretty bad. This kind of absolute statement shows more than anything else that you know very little about this subject. You've probably given Eclipse a cursory glance, decided that it isn't NetBeans, and decided it was shit because you couldn't grok its way of doing things. Of course the fact that every IDE forces you to adapt to its way of doing things and requires a substantial time investment in order to be able to use it well. I've spent considerable time using NetBeans, IDEA and Eclipse. And each time, the process of learning the new IDE was a serious pain. Welcome to the real world. Spend more than 5 minutes with Eclipse and you'll realize that it does a ton of stuff better than NetBeans and a bunch of stuff poorer than NetBeans.
it includes functionality out of the box (JSP compilation) that you need to pay for (MyEclipse) with Eclipse.
Wow...that's functionality that takes all of 5 minutes to setup using Ant. That's all NetBeans is actually doing anyways. Of course if my build script is called build.xml (like > 90% of them are), NetBeans can't use it.
Meanwhile, when it comes to truly necessary features, like AspectJ, NetBeans has no support. By the simple lack of AspectJ support, NetBeans would go from superior in every way to unusable.
So somehow advocating that Sun follow IBM's lead is simply IBM's being selfish. Advocating that Sun give developers the option to write SWT apps is IBM polluting "the standard" (which is only the standard because Sun says so). And so those of need our apps to look native have to bundle SWT with our apps. Thanks, Sun, for keeping the standard so pure(ly unusable)!
Yeah, I'm replying to a (Sun) troll...He probably also believes that EJBs scale...
Go to any Job recruitment site and try a search on the keywords Java and the keyword C++ and I think you will get some idea of the use of these two languages. (You might check out C# and VB whilst you are at it).
I followed your advice and downloaded a 30 day trial. I must admit that I was impressed with its performance and memory footprint. I decided to compared it with Visual Studio 2003 Enterprise Edition in terms of memory and loading time.
IntelliJ: 65 MB 10 seconds
Visual Studio: 14 MB 4 seconds
I didn't mind its memory footprint and loading time. You are right in suggesting that Swing is competitive in that area if used correctly.
What I consider to be unnacceptable is its fonts. They are terrible. It looks like a 5 year old application. Lets hope that "mustang" does a better job. Even if it does, it would have only succeded in catching up 5 years late.
According to http://www.jcp.org/en/jsr/detail?id=14, discussion on generics officially began on May 11, 1999. (Exactly seven years ago.)
According to http://www.jcp.org/en/jsr/detail?id=201, discussion on enums, foreach loops and autoboxing officially began on December 3, 2002.
According to http://www.jcp.org/en/jsr/detail?id=175, discussion on annotations officially began on March 19, 2002.
Those are just the beginnings of formal proceedings. It's probably safe to assume the concepts were in someone's head well before those dates. The JCP doesn't just let every whimsical thought immediately become a JSR, after all.
But you shouldn't need hard dates. Compare how many times Microsoft has created something from scratch successfully, with how many times they've copied other people's work. Suggesting they invented those language features is like suggesting AOL invented the Internet.
The Internet is full. Go away.
10 years to catch up with other toolkits after years of bad performance causing customer ill will and marketing lies about who's at fault. Uhh... hurrah?
See, this is what Gosling is apparently missing. Whether the source code is theoretically available or not, the open source community is never going to be happy about a license that's so restrictive it even dictates what command line arguments you are allowed to use when running the software.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
We're running 2.4 GHz machines,
I'm running a 1.8 GHz machine, thanks. And the machine in the corner over there is 566 MHz.
and Java is just as quick and responsive as any other app.
Eh... slightly but noticibly less responsive and eats more memory. But that's with SWT on Windows...
You can write your app in Java, or you can add 10% more features.
> Exactly. I think that the people calling for Java to be open sourced don't get the concept.
On the contrary, I think it's you who doesn't get the concept! I like (for example) OpenBSD because they're very compulsive about the testing. Yet they are open source! No one is asking for Java-the-language to change! Or the development model. Java can continue to be developed and husbanded by Sun just fine, even if it's open source. All we are asking for is the right to control our own machines IF PROBLEMS ARISE! And the right for our vendors to provide better integration--even those of us who use open-source-only vendors!
There seems to be a large segment of the population who think that being "open source" means that anyone can modify the code and stick in whatever they want. Well, guess what--that's STUPID! Sure, Joe Blow could, in theory, make his own weirdo variant of Java, but WHO WOULD USE IT? If Sun's version is indeed as good as you claim, nobody is going to want any third-party variants! Whether or not it's open source! Microsoft might try to make an incompatible version? Here's some news for you--THEY ALREADY DID, and they named it C#!
Java being open-sourced is unlikely to have any impact on the language or how its developed. So, why do we care? Because having it be open-sourced is the ONLY WAY that it will EVER be included with and supported by Debian, Fedora, OpenSUSE, Ubuntu, the BSDs, etc., etc., and many of us use those systems on a daily basis! And we see no sign (based on all the software included with those systems) that there would be any possible downside to an open-source Java.
So, please take your straw men and your red herrings and go peddle them elsewhere!
Okay, let's do a comparison:
* Swing: cross platform
* SWT: cross platform
* Cocoa: not crossplatform
Hmm, this is a hard choice...
We already have a typesafe OO language: Ocaml. You can read more about it at ocaml.org.
Those of us in the know have been using it for years for very significant applications. Besides offering native compilation on most popular UNIX platforms and Windows, it also offers a bytecode interpreter. The performance of both is superb.
That's your fault.
Editable table cells are an idiocy. They're a contrivance that some fool stuck in there because people saw a JTable and immediately reacted with "it looks like a spreadsheet."
Can you think of any native widget set, anywhere, that provides editable table cells? An embedded Excel component doesn't count.
There are dozens and dozens of open bugs regarding editable table cells. As a user interface, they suck. Do yourself and your users a favor and don't ever use them again.
More to the point, since they aren't part of any existing widget set, there's no specification for their behavior. The reason all those bugs exist is that no one has ever defined how editable cells should behave! The closest reference is Excel, but it has almost no other objects which can take focus, so it can't define focus behavior.
And no, you do not need editable table cells. Want to let the user change a text value? Have a button that brings up a little prompt dialog. Want to have changeable boolean values? Have nearby buttons labeled "Enable" and "Disable" (or whatever applies to your boolean column). You'll even gain the side benefit of letting the user change several rows at once, which is probably a better interface than forcing the user to individually click a checkbox inside a cell on each of the fifty rows he wants to change.
The Internet is full. Go away.
Practical experience on my OS X box leads me to the conclusion that Java is as slow as ever. Take an application like Art of Illusion, and you can see the lagginess in the GUI and the painful slowness of simple operations like "Save."
Comment of the year
Also remember things like drag&drop, integrated spell-checker, support for text-to-speech code (the "speak text" command in the Edit menu), AppleScript responsiveness... those are all part of the "feel" of Mac OS, and Java doesn't do any of them.
Comment of the year
Sounds like someone decided to sleep instead of going to lectures.
I'm a few years out of programming languages, but it sounds to me that you're butchering the use of dynamic vs. static languages. To my knowledge, dynamic/static is used in programming languages to refer to two properties: scope and typing. This is, of course, not to be confused with compiled vs. interpreted languages.
So, why are dynamically typed languages popular? They're popular because they know how to do things implicitly. We get these niceties like the ability to use numbers as strings without calling atoi, or use input strings to do math. Basically, dynamic typing lets you code faster because you don't have to constantly worry about casting things to the appropriate type.
Dynamically scoped languages are, in my opinion, rarely useful. The only valid use that I have ever had is to temporarily override a global parameter. For example, in Perl I might call local $/ = undef ; to temporarily enable 'slurp mode' in Perl. However, this is pure laziness, I could just as easily store $/ in a temporary variable and restore it when I'm through. Finally, even though languages like Perl are dynamically scoped, a sane programmer would never take advantage of this feature. How can you debug a value when you aren't sure where it came from?
Finally, Java/C are not free from runtime type detection errors. Java will happily throw a ClassCastException if you try to cast an Object to something that it is not. C makes it even worse and will dutifully make the cast and entirely muck up your data structures when you try to use the improperly cast object.
In my opinion, people don't use languages like Ruby/Perl/Python because they are superior architectures. They use them because they are easier to learn.
I think you need to cut down the number of blogs you read..
You're taking my post way too seriously...
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
> Can you think of any native widget set, anywhere, that provides editable table cells? An embedded Excel component doesn't count.
I don't know. Does Windows Explorer in 'details' view count as a table? Clicking on the headers, resizing, or clicking on some other component while editing a filename seems to have decent non-retarded behaviour, that is, commit the changes.
Speaking as a user and not a developer, I consider that good default behaviour. Doing the same thing with the Swing windows-imitation file browser (viewing files in detail mode) causes the edits to be lost.
Ahem and what pretell is the c-cdoe in Awt based on perchance?? Give you a guess Unix, Windows, andother platform windows toolkit apis.. Gosling should know better thanb to spout off PR bullshit.. SWT is not based on Widnows UI kits as it plugs into not windows UI kits but systme apis.. instead..
Fred Grott(aka shareme) http://mobilebytes.wordpress.com
Yeah, that's because all the poor fucking companies developing their
applications in Java end up needing 10x as many programmers and 4x
as much time as they thought they would.
Java gets you 80% of the way there very quickly.. then you want to
do something a bit different to what the standard library wants to
provide and you end up dipped in dogshit.
Posted anonymously to protect my company's share price.... I wish
to fuck I had never let my senior partner insist on going down the
java path. I swear to God I would be rich by now if we had used C++.
I don't use OSX, but under windows drag and drop between java apps and non-java apps certainly works.
Yep,
I've written my fair share of SWING apps, and they all suffer to some degree or another cross-platform compatibility issues (running on an SGI NT Box turned the whole screen orange), as well as slow refresh speeds and occasional problems not updating the screen at all.
Professional SWING apps seem to mitigate this somehow, but perhaps it requires some deep magic I'm not familiar with. A friend of mine had a SWING app that took 3 minutes to redraw the screen. I could at least help him with that one (he was wastefully putting way too many components on the screen), but nothing I ever experimented with could solve the aforementioned problems.
Okay - I don't understand.
If Swing is good, and Eclipse is good, but Eclipse uses SWT which breaks interoperablity, is there a way to use Swing with Eclipse?
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Why no love for Obj-C? 'Cause it was a discussion about Java, of course!
Also, I've never done any programming for the Mac (except for UNIX console apps in C), so I have no idea what I'm talking about anyway. I was just trying to be funny.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I think the big mistake Sun has is that it is confusing what people mean by open source. When someone says open source they mean not only is the code fully open source but you can change it, redistribute it, and even submit patches to Sun. If you look at http://www.sun.com/software/communitysource/j2se/j ava2/download.xml you will see a few files for the Java souce code. One is simple labeled "JSCSL Source" but another is labeled "SCSL Binaries - needed to complete source build" so Java isnt fully open source. The first thing they need to do is make it so I can download just the source, with no binaries, and compile it on any OS/arch mixure I want. The second thing they need to do is change the license just a bit so that I can redistribute the source code on my own. I think most people would be fine with Sun making their own license that says you must say it isnt the offical Sun Java if you choose to redistribute it. I think right now Sun's big problem is that they dont want something stupid that you do effect Java's reputation.
I wrong a Java app to let me do a few things in school and the Swing file open dialog gets past most of their security. I can open many files which are block under win normaly. I dont know if thats a big with Windows, Java, or Novell(they use that to block everything) but its pretty funny/cool.
WTF! Do you actually have a job or are you 14 and living with your parents? You've obviously got 0 understanding of the real world, or your just too dim to be anything but a script kiddy. PS. I'm not new here, just fed up with script kiddies ;-)
Dum spiro spero
On a related note: would anybody know if IBM's rendition of Java is open sourced?
Your knowledge in this matter is obviously lacking.
With respect to programming languages, 'dynamic' and 'static' are oft used to describe when typechecking takes place. Many languages, like Java, offer some degree of both. Static typing is when the datatypes of variables, arguments, etc., are determined and verified at compile time. Dynamic typing is when such information is determined at runtime.
The very least you could do at this time is go to Wikipedia, and read up on such things. At least then you'll understand what is being said here. Of course, there are also many textbooks available that cover these topics, but frankly I don't think you're at a level of understanding to even begin to comprehend them.
I don't know why you're talking about scope. It has nothing to do with this topic whatsoever.
And your analysis of dynamic languages is completely mistaken. In many dynamic languages you do have to take care to convert data of different types into compatible forms in a correctly-functioning program. Basically, everything you said in that paragraph is incorrect.
The main problem with dynamic typing is that you could easily (without warning from the compiler or interpreter) pass the string "Hello" to a function or method that takes an integer. At least with a statically typed langauge, such a mistake would be caught by the language implementation, and you'd have to manually override it (ie. with a type conversion function, a cast, etc.). If such an error is in a codepath that is called infrequently, you may very well never find the error until you have shipped the software. Nothing sickens a customer more than finding such bugs. And any developer who is responsible for such easily avoided issues should be ashamed.
It was not suggested that Java nor C were immune from runtime type errors. Indeed, any language that allows casting opens itself up to problems. A language like Haskell does not allow such reckless behavior, and as such is far safer. Typing errors are always caught at compile time, not at runtime.
In any case, you are obviously quite confused about the differences between statically typed and dynamically typed languages. Please read up on these subjects further, before you make a fool out of yourself again.
Indeed, MS wanted to implement (nobody claimed MS "invented" any of this) most of those features in Java about 8 years ago, but Sun sued them. When MS couldn't put the features into Java, they went ahead and created C# and put the features there instead.
People have been experimenting with generics in Java for 10 years now. The only reason Sun actually shipped an implementation of it is because they had to compete with MS. I can understand why it would take a long time though, because there's no easy way to do generics in Java without breaking precious compatibility, so they had to resort to type erasure.
Of course MS had enumerations built into Java back in 1998. Why did it take Sun 4 years to even start discussing it? You'll notice that they started discussions on foreach, autoboxing, enums, and annotations in 2002. Microsoft shipped C# with those features in 2002 (although I first read the specs in 2000). Coincidence?
dom
Unmiserly but teething Beast It is Twisting and seething And of discordant beliefs Oh a wonder! Or haphazard miracle I don't mind all the parentheses But standards from commercialism should have died in the 80's.
I worked with IBM Object Technologies Inc, the original author of the Standard Windowing Toolkit when Eclipse was so new that they wouldn't even release test copies to developers working with IBM and OTI. SWT originated as a layer that OTI was using for implementing a cross platform compatability layer to allow porting AWT and Swing to mobile platforms to be easy.
The fact is, since I have extensive experience working on SWT from porting it, I can clearly say that it definately was not a Windows based toolkit in anyway. Long before hearing about Eclipse, SWT was already ported to many different platforms.
SWT had its problems. Even propagation was probably the most complex of them, but in reality, it was no more or less platform dependant than AWT itself. If you've ever read the code from Sun for AWT, you'd know that it was somewhat of a disaster. It was a nasty compatibility layer that instead of embracing platform differences, was minimized to remove the difference instead.
I have ported AWT to two windowing toolkits and frankly, time and time and time again, I found that the only practicle way of making AWT work on a new platform/windowing toolkit was to implement an SWT style GUI library in Java first, then build the AWT layer on top. This was also nasty in a way since it meant that it was extra important to make the new windowing toolkit not suffer the same incredible limitations that AWT itself did.
Also, let me make it perfectly clear, AWT and Swing, no matter how you skin them, they never integrate into the platform nearly as well as building on the native toolkits. SWT was the first widely used library that ever put an effort into recognizing that a Windows user is a Windows user, a KDE user is a KDE user, a GTK user is a GTK user, and a Mac user is a Mac user.
Sun should be bowing down and thanking IBM OTI for the creation of SWT, in fact, Sun should be rebuilding AWT and Swing on top of SWT since their own code base is so very limited in comparison.
Ha, nice! well...ya had me going there ;)
"Personal ownership is a hallmark of conservative capitalism. And I don't believe I am entitled to anything that I did n
I'm guessing it was because of things like this. Java has done its best to avoid language bloat; the common term for it is "less is more." It's easy to accomplish the equivalent of an enum using a private constructor and public static instances. So a language-supported enum was regarded as unneeded.
The Internet is full. Go away.
Well, Sun can surely do as they please, but that just means that .net is more likely than Java to end up on linux and solaris machines in the near future. If that is what Sun wants, then that's what will happen. Or why do you think mono popped up out of nowhere?
.NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications.
from the mono homepage:
Mono provides the necessary software to develop and run
Look, there is a munchillion people out there, that have learned Java at uni or at work.
These people just ache for releasing their open source project in all it's open source gloryness, and dreams of having it included in all the major GNU/Linux/FreeBSD/*nux distros.
This is an enormous potential, that is destoyed by not having a version of Java included in all open nuxes, by default, that is easy to work with and works as they expect. Not to speak of extremely security-minded companies, that only work with open source.
And, as long as Sun's Java isn't proper open source, it is not going to be their version of Java that's running everywhere.
Why Sun doesn't see that this is where the problem lies, not with the actual looking at sourcecode, beats me.