Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
144 -
Pages:
10
[
Previous |
1
2
3
4
5
6
7
8
9
10
| Next
]
Fresh Jobs for Developers Post a job opportunity
» Dieselpoint, Inc seeks a Senior Solution Engineer - Enterprise Search in Chicago, IL 60661 » DZone, Inc. seeks a DZone Developer Intern in Cary, NC
Re: Unified Development Eclipse and NetBeans
> The point is that not having a full VM can hardly be> construed as an advantage no matter how you want to
> paint the picture.
Is gij missing something obvious from the VM specification that makes it a not-that-full VM? I'm puzzled.
> >Have you ran the TCK on Kaffe? If you have not, how
> do you know it's incompatible? Or are you just
> spreading FUD for FUD's sake?
>
> I included the state of compatibility as far as
> the kaffe site has it in the forms of two links which
> site 1.3 and 1.4 compatibility.
These pages reflect API coverage. In absence of the TCK, I can't make compatiblity statements regarding Sun's implementation. As I don't have access to it, I can only guess from crumbs of information that Sun's compatibility test suite covers something else than binary compatiblity as defined in the JLS 2.0, which is all japitools (the tool that generated that output) looks for.
So 7x% of J2SE 1.3 may mean Kaffe can pass the secret J2SE 1.3 TCK, or it may not mean it, depending on whatever the secret TCK tests for. I can;t tell. Can you?
Once the secret TCK becomes available for running against it, I am certainly looking forward to seeing the compatiblity tests for the funny public RCSID fields in Swing
cheers,
dalibor topic
GNU Classpath - Core Libraries
IRC: irc://irc.freenode.org/#classpath | irc://irc.freenode.org/#kaffe
Re: Unified Development Eclipse and NetBeans
Its difficult to discuss something like this when you don't even take the Kaffe site's results at face value.Cheers.
Charles
Re: Unified Development Eclipse and NetBeans
NetBeans uses javac. Javac is distributed under the same license as Java is, so, yes, you agree to that license (just as you did if you're using a Sun JDK) when you build NetBeans. Should we have written our own compiler? Don't think so - look at all the pain Eclipse has had to go through to support JDK 1.5 precisely because they reinvented every wheel in sight.The same is true of a couple other libraries, like JavaHelp and Java Metadata Interface; all of these are standards that went through the Java Community Process. I don't see using standards as a bad thing; I suspect most others wouldn't either.
All of NetBeans codebase is open source. Period.
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Unified Development Eclipse and NetBeans
Okay, Guillaume, I understand what you are referring to now.NetBeans is tightly tied to some of the JDK components (funny - but I thought people would want their IDE tied to not only the Java runtime but also the developer pieces). NetBeans sources *are* open source.
As far as I know, NetBeans is using the Java standard, NetBeans naturally doesn't opt to rewrite all those JDK pieces. NetBeans is tightly integrated with elements of the JDK. So it uses for example, javac. There is certainly no crime in this - in fact it is advantageous in many ways. To repeat : NetBeans code is all open source; if it uses a Java standard, it is used under its license. We're not talking about any third party commercial libraries.
Since your main concern seems to be J2SE licensing, stay tuned.
Cheers.
Charles
Re: Unified Development Eclipse and NetBeans
> Its difficult to discuss something like this when you> don't even take the Kaffe site's results at face
> value.
I fail to understand what you're trying to say. I know what japitools are and what they do, and I've looked a bit at that code and hacked a bit on it, too, so I am puzzled at what I should take at face value: I know what the output means. And it as it doesn't mean a compatiblity statement beyound binary compatibility as defined in the JLS, so as you didn't say what you mean by saying Kaffe is incompatible, I'm just interested in figuring out what the basis for such a claim is.
As the TCK is not public, which is for all I know Sun's compatibility oracle, and Sun's own compatiblity testing is performed according to some unspecified rules, with some unavailable[1] test suite, resulting in unpublished output, it would be interesting to know a bit more about those secret proceedings and rules, and if there is something that says in the TCK that a runtime must implement all of the ABI of J2SE, no matter how useless (see my RCSID example) it is. I am curious.
cheers,
dalibor topic
[1] Unless one is really out of reading material and the phone book is too boring. Yay for the 'Read-only license', ts ts.
GNU Classpath - Core Libraries
IRC: irc://irc.freenode.org/#classpath | irc://irc.freenode.org/#kaffe
Re: Unified Development Eclipse and NetBeans
> I know you have something in mind but I'm not sure what.You're right, I would like to use Netbeans. And I can't.
(btw, because NB uses un-standard calls, it can not be certified as a Java(tm) app).
Re: Unified Development Eclipse and NetBeans
> Whoa! If you don't mind running a development VM that> is incompatible - fine.
There is misunderstanding here. I don't mind running the IDE on a not-fully compatible VM. But the development VM I used depends on the project. In general, it will be Sun JRE 1.5 but sometimes kaffe (or more rarely gcj).
Please note that Kaffe is not incompatible, just not fully compatible.
> > Compatibility with 1.4 is a work on progress.
> > According to my tests, compatibility with 1.3 is much
> > higher. So Kaffe is a good choice (and often the only
> > choice) to run Java 1.3 programs.
> And since you brought up 1.3 here is the link for 1.3:
> 78.77% by the Kaffe site's own tests.
Right. But if you remove CORBA, Swing and JavaSound, you're very close to 100%. And when I use Kaffe, I don't need these APIs (because I can use a free broker and swing 1.1).
Re: Unified Development Eclipse and NetBeans
Hi Charles,> Okay, Guillaume, I understand what you are referring
> to now. NetBeans is tightly tied to some of the JDK
> components.
It is tied to some components of the JDK. This is not a problem because these components are available on my box and because they are part of the standard JDK. But NB is also tied to 46 other scrambled components. Some are opensource but most of them are not. And they are essential for building Netbeans IDE.
> NetBeans sources *are* open source.
Yes the source code is open source. But a raw estimate is that source code is about 20% of Netbeans IDE.
> As far as I know, NetBeans is using the Java
> standard, NetBeans naturally doesn't opt to rewrite
> all those JDK pieces.
It uses a lot more than that.
> NetBeans is tightly integrated
> with elements of the JDK. So it uses for example,
> javac. There is certainly no crime in this - in fact
> it is advantageous in many ways.
No it is not a crime to use javac because javac is part of the JDK (it would be nice to have an option to specify another compiler like ant does).
> To repeat: NetBeans code is all open source
Yes, the source code is opensource. But the source code is not available for all the modules. Basically, you can not build anything functional without using non-opensource modules.
> if it uses a Java standard, it is used under its
> license.
No problem here. This covers servlets-*.jar, ...
> We're not talking about any third party commercial
> libraries.
I do. For example, Javahelp, JMI, J2EEeditor, MOF, Flute, ... I think these modules are neither standard nor opensource.
> Since your main concern seems to be J2SE licensing,
> stay tuned.
My main concern is a "better" Java (faster, lighter, ...). After years, I think it can only be achieved by having an opensource J2SE because this is too much work for Sun. My second concern is WORA, that implies having the JRE on any architecture (portable and ported). Opensource again.
To get back to the initial topic, I really think that the fact that Eclipse is fully opensource and runs on Free runtimes is what makes it successfull.
In all cases, i'm staying tuned, hoping for some changes in J2SE licensing. Especially for the CORBA, JavaSound and Swing APIs.
Regards, Guillaume
Re: Unified Development Eclipse and NetBeans
Hi Tim,> NetBeans uses javac. Javac is distributed under the
> same license as Java is, so, yes, you agree to that
> license (just as you did if you're using a Sun JDK)
> when you build NetBeans. Should we have written our
> own compiler?
No. (But I would like to have an option to use other compilers. I really like Jikes, because it gives accurate semantic warnings)
> The same is true of a couple other libraries, like
> JavaHelp and Java Metadata Interface; all of these
> are standards that went through the Java Community
> Process.
Standard does not mean opensource. Using standard APIs is a good thing. I'm just pushing for opensource implementations of them.
Netbeans contains 39240723 bytes of scrambled compressed code. How much is opensource, how much is standard, how much is neither standard nor opensource?
One more point, when you say standard, you mean JCP. How many modules are standard under a license that prevents opensource implementations?
> I don't see using standards as a bad thing;
> I suspect most others wouldn't either.
I see using standards a very good thing. As soon as they are real standards, authorizing opensource implementations.
> All of NetBeans codebase is open source. Period.
All of Netbeans source code is open source. The available source code covers a small part of the Netbeans IDE product.
Netbeans is a good product. I just think it would have more success if it was fully opensource. Same for Java. Same for Java3D. Hoping for good news at JavaOne'2005
Good continuation,
Regards, Guillaume
Re: Unified Development Eclipse and NetBeans
Specifics please?OTOH I can think of one UI class for a (unused but I think there for backward compatibility because someone foolishly made it a public class) component that extends something in the Windows L&F - but that would only ever be loaded if you were running Windows L&F to begin with; at worst it's easily stubbed. Anything you find like that we'll be happy fix or find a workaround for; there's a pretty strong ethic not to do that sort of thing, and plenty of possible workarounds if it's causing someone a real problem.
Or are you talking about the fact that we call javac?
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Smoke and mirrors...
> If there is any doubt that Eclipse is owned and> driven by IBM you should take note of this. I picked
> up the EclipseCon bag when I registered. There were
> two cd's in the bag. Actually, two DVDs of software.
> Both identical DVDs with nothing but IBM software on
> them. Not a single bit of software from another
> Eclipse Foundation member. I think that speaks
> volumes as to what Eclipse really is.
hmmm, sounds like someone is posting some FUD about Eclipse and EclipseCon.
To set the record straight, anyone had the opportunity to have a promotional item entered into the EclipseCon conference bag. Gold sponsors of the conference had this benefit included in their sponsorship package. Other companies could have purchased this benefit for $750. In fact over 15 companies inserted promotional marketing literature into the bag, including BEA, Borland, IBM, Sybase, etc. Any of these companies could have inserted a product CD but only IBM choose to do so. Eclipse or EclipseCon did not dictate what the company inserted.
Regards,
Ian Skerrett
Eclipse Foundation
Director of Marketing
Re: Smoke and mirrors...
[ My Opinions are my own ]Your statment whether true or not doesn't negate the fact that the only DVDs and software distributed was IBM software. Kind of an unfortunate subliminal message for an 'open' software consortium. Compare this with JavaONE where I have received CDs/DVDs from IBM, Borland, Oracle and host of other companies in the traditional bags. Or for that matter other conferences.
Cheers.
Charles
Re: Unified Development Eclipse and NetBeans
> Hi Tim,>
> > NetBeans uses javac. Javac is distributed under
> the
> > same license as Java is, so, yes, you agree to
> that
> > license (just as you did if you're using a Sun
> JDK)
> > when you build NetBeans. Should we have written
> our
> > own compiler?
>
> No. (But I would like to have an option to use other
> compilers. I really like Jikes, because it gives
> accurate semantic warnings)
Agree about the warnings. There's work going on now to get better error recovery out of javac == better ability to detect what's actually wrong in the source.
> > The same is true of a couple other libraries, like
> > JavaHelp and Java Metadata Interface; all of
> these
> > are standards that went through the Java Community
> > Process.
>
> Standard does not mean opensource. Using standard
> APIs is a good thing. I'm just pushing for opensource
> implementations of them.
>
> Netbeans contains 39240723 bytes of scrambled
> compressed code. How much is opensource, how much is
> standard, how much is neither standard nor
> opensource?
Here's the list. For most of the items, it's pretty clear what they are. Remember some of these will be used by modules that are not part of the standard distribution (for example, the Docbook XML DTDs, used by an experimental plugin to do slide presentations in NetBeans), and some are for modules that are no longer active, but are still there. So if we were actually looking at just the things to have NetBeans and basic Java support up, it would be much smaller.
Note also the vast majority of these things are open source:
So we've got XML parsers, Ant, Jalopy, PMD, JUnit, some XML parsers & such, JTidy, CSS parsers (flute, sac - open source, I believe) probably a few other things in the open source list.
In the standards category you've got the Servlet API, MOF (an OMG standard), JMI (a JCP standard), the JSP standard tag library, JavaHelp (jhall*.jar), the Jini starter kit (jini*, sun-util.jar*), the JSP API & Docs, and similar things.
In the non-open source category, you've got the Sun Appserver (don't need that to do a build), the html of the Java Blueprints Solutions catalog (don't need that either).
Anyway, that's not an exhaustive run-through of the list - I don't hold in my head what every jar is; if you want to pick nits or ask about specific items, let me know. The point is, there's nothing nefarious going on here. The "scrambling" is a convenience for developers that allows them to get everything they need from CVS, and satisfies the lawyers that all the licenses were agreed to (including the open source ones).
> One more point, when you say standard, you mean JCP.
> How many modules are standard under a license that
> prevents opensource implementations?
I don't know what OMG's policy is on that, and MOF is an OMG standard. Everything else is JCP, which as far as I know allows that just fine.
> > I don't see using standards as a bad thing;
> > I suspect most others wouldn't either.
>
> I see using standards a very good thing. As soon as
> they are real standards, authorizing opensource
> implementations.
>
> > All of NetBeans codebase is open source. Period.
>
> All of Netbeans source code is open source. The
> available source code covers a small part of the
> Netbeans IDE product.
Small? Hardly! There's a lot more code that's built from NetBeans source base in a distro of NetBeans than in libraries. The idea that the available source code is a small part of overall NetBeans is nonsense - believe me, I work daily in NetBeans source base - you make it sound like there's five classes and a thousand binary libraries. That's wrong.
But since I'm spewing console output into this message, let's have a look. Bear in mind the number of bytes in libraries you mentioned, and compare it with the entire set of jars in a NetBeans distro. I think this makes relatively clear (note some jars like copyfiles & wsclientuptodate are part of NetBeans source base, they're just Ant tasks, so not prefixed with org-netbeans):
Anyway, if you really want, in my copious free time (!) I can give a canonical answer for what every jar is and where it comes from. As that won't be interesting to the vast majority of people here, we should take that offline.
-Tim
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Unified Development Eclipse and NetBeans
> > a> href="http://www.kaffe.org/~stuart/japi/htmlout/h-jdk1
> 3-classpath.html">http://www.kaffe.org/~stuart/japi/ht
> mlout/h-jdk13-classpath.html
>
> Note that it is not all that much more compatible :
> 78.77% by the Kaffe site's own tests.
If I understand these charts correctly, they are just
showing method signature and field signatures, not
any actual functionality. I would think anyone could
get that chart up to 100% in a couple of days' work.
More important though, is whether the libraries actually
*work* the same. Which, of course, is several orders
of magnitude more difficult than getting the APIs to
match.
Andy
Re: Unified Development Eclipse and NetBeans
Maybe I can help...Dalibor, I think what Charles issaying is that if Kaffe has only implemented 77% of
the API, it's not compatible, regardless of what
the TCK tests.
My own view is that I don't really care how much the
TCK tests, I just care whether tools like Eclipse
actually run, *and* run about as bug-free as
"pure Java' apps. Whether something runs or not
is not a binary thing. I need to be completely
confident that Eclipse (or any other thing that
uses a non-Sun-blessed JVM) will run without
major problems caused by the underlying JVM.
Pulling in the TCK is only distracting from the
core issue. I can tell without even looking at
the TCK that a JVM could pass it, but still have
major problems when running real-world apps.
And vice-versa: a JVM may exist someday that
runs real-world apps very well, but doesn't pass
the TCK.
Andy