[Java] src.jar + packaged en native

[Verwijderd]

Hey, ik zit tegenwoordig veel in de src.jar aan het kijken als ik een klasse wil extenden. Alleen heb ik het gevoel dat ik een groot deel mis. Volgens mij zijn best wel veel belangrijke dingen of package-private of native, en die code zou ik ook wel eens willen doorsnuffelen.

heeft iemand toevallig een linkje naar de complete sourcecode van Java(1.4/1.5)
alvast bedankt

enne, ik vind dit niet echt een scriptrequest dus openlaten

[Gert]

Ik dacht dat niet alles openbaar is, nog niet tenminste.

[Onno]

Complete broncode is al jaren zo te downloaden.

http://java.sun.com/j2se/1.5.0/download.jsp

"Download JDK 1.5.0 source"

[Robtimus]

Als je de SDK installeert dan zit daar een src.zip file in, met daarin de complete source van wat openbaar mag zijn (dus geen sun.XXX packages). Iig bij de 1.4.2 SDK.

[ronaldmathies]

Op de Sun site kan je alles downloaden van 1.5 :

http://java.sun.com/j2se/1.5.0/source_license.html

Dit is dus inclusief de sourcecode van de JVM.

[tjerkw]

Verwijderd schreef op zaterdag 26 februari 2005 @ 00:52:
Hey, ik zit tegenwoordig veel in de src.jar aan het kijken als ik een klasse wil extenden. Alleen heb ik het gevoel dat ik een groot deel mis. Volgens mij zijn best wel veel belangrijke dingen of package-private of native, en die code zou ik ook wel eens willen doorsnuffelen.

Dat je die code wilt doorsnuffelen snap ik... maar dat je naar de broncode kijkt als je een klasse wilt extenden?? Daar zijn de API's voor. Of gebruik een goede IDE, bijvoorbeeld netbeans. die helpt je met alles.

[Verwijderd]

De bron code *is* de API. Zelf kijk ik altijd direct naar de source ipv naar externe javadoc. Met een goeie IDE (zoals Eclipse) is dat een piece of cake (bijv. F3 om direct naar een klasse te springen, maar ook bijv. even de javadoc zoals die zou worden gegenereerd bekijken). Verder is het superhandig om door door source heen te kunnen steppen met een debugger.

Daar heb je direct nog een reden om de source te downloaden; je kunt dan je JDK hercompileren met debugging info aan, zodat je ook in bijv. de JAAS API etc. al je debugging info hebt.

[tjerkw]

Verwijderd schreef op zondag 27 februari 2005 @ 16:31:
De bron code *is* de API.

fout de bron-code is zeker niet de api. OK, de bron-code bevat ook de api, maar de bron-code is meer dan een api. Een api is een beschrijving van de interface van een bepaald systeem (Application Programmer Interface). Die interface (classen namen. methoden met beschrijving etc) staat los van de implementatie. In principe maakt het jou niet uit wat er in een methode van KlasseA.doThis(Object arg1, Object arg2) staat.. zolang die maar doet wat ie zegt dat ie doet.

Zelf kijk ik altijd direct naar de source ipv naar externe javadoc. Met een goeie IDE (zoals Eclipse) is dat een piece of cake (bijv. F3 om direct naar een klasse te springen, maar ook bijv. even de javadoc zoals die zou worden gegenereerd bekijken). Verder is het superhandig om door door source heen te kunnen steppen met een debugger.

Over het algemeen wil je niet door code van iemand anders gaan debuggen. Neem een stable lib. Soms is het wel handig om door de java code heen te debuggen.. maar dan debug je door de interface neit door de implementatie.

Daar heb je direct nog een reden om de source te downloaden; je kunt dan je JDK hercompileren met debugging info aan, zodat je ook in bijv. de JAAS API etc. al je debugging info hebt.

Waarom wil je in de source van de java lib bladeren.. of hercompileren.. ik vat het niet. dat wil je toch niet veranderen.?

[Verwijderd]

ok, dat is inderdaad de formele definitie van een API. De rest van de wereld bedoelt gewoon dat stukje software, interface/class/methode/component/whatever waarop je op dat moment wil aansluiten. Formeel heb je dus gelijk dat ik niet gelijk heb Echter wat is die JDK API dan? Bedoel je dan de Javadocs, of de specificaties (die bestaan nml slechts voor een subset van de gehele JDK).

Niet handig om door de sources van anderen te steppen? Pardon? Daar denken we dan echt verschillend over. En stable libs bestaan niet. Ik heb nog nooit een lib gebruikt die geheel zonder bugs was. Alleen afgelopen twee weken al heb ik twee bugs in de Eclipse java compiler gevonden bijv. En nog een aantal in Groovy. Daarom is het ook zo prettig om met open source projecten te werken, zodat je - als er wat aan de hand is - je kunt nagaan of het je eigen fout is of dat het aan een van je dependencies ligt.

Trouwens, waar ik de afgelopen jaren het meest van geleerd heb als programmeur is om eens even goed door de sources van een lib heen te gaan. De Eclipse API (issie weer) bijv.; daar zitten gave patterns in die ik verder nergens heb gezien. Of waar ik nu actief voor ben: http://wicket.sourceforge.net. De initiator van dat project heeft zelf aan AWT en Swing meegewerkt, en dat is duidelijk te zien in de elegantie waarmee hij zaken oplost. Dit is bijvoorbeeld de eerste keer dat ik het Vistitor pattern mooi en praktisch zie toegepast. Daar krijg je zelf ook gewoon weer goeie ideeen van.

Vwbt het hercompileren van de java sources... Ik heb het momenteel niet klaarstaan, maar ik heb wel momenten gehad dat ik echt even door de JDK wilde steppen om helder te krijgen hoe bepaalde stukken werken. Bijv. JAAS. Dat werkt best ingewikkeld. Probleem is echter dat de JDK zonder debugging info is gecompileerd, waardoor een hoop variabele informatie etc niet beschikbaar is als je er doorheen stept. Als je dit toch wil doen kun je zelf de JDK hercompileren met debugging info aan. Niet dat je dat dagelijks wil doen... maar het kan.

[tjerkw]

Verwijderd schreef op zondag 27 februari 2005 @ 18:03:
ok, dat is inderdaad de formele definitie van een API. De rest van de wereld bedoelt gewoon dat stukje software, interface/class/methode/component/whatever waarop je op dat moment wil aansluiten. Formeel heb je dus gelijk dat ik niet gelijk heb Echter wat is die JDK API dan? Bedoel je dan de Javadocs, of de specificaties (die bestaan nml slechts voor een subset van de gehele JDK).`

de api is over het algemeen de javadoc. Maar kan zijn dat de api op een andere manier wordt geleverd. (bijvoorbeeld .java files zonder de implementatie, volgens mij is het zo ook in src.jar gedaan).
En de specificaties hebben niks met de api te maken. Over welke specificaties heb je het eigenlijk? De JVM specificaties?

Niet handig om door de sources van anderen te steppen? Pardon? Daar denken we dan echt verschillend over. En stable libs bestaan niet. Ik heb nog nooit een lib gebruikt die geheel zonder bugs was. Alleen afgelopen twee weken al heb ik twee bugs in de Eclipse java compiler gevonden bijv. En nog een aantal in Groovy. Daarom is het ook zo prettig om met open source projecten te werken, zodat je - als er wat aan de hand is - je kunt nagaan of het je eigen fout is of dat het aan een van je dependencies ligt.

mm.. ok het kan handig zijn .. in principe report ik de bugs gewoon zodat de maker het kan fixen.

Trouwens, waar ik de afgelopen jaren het meest van geleerd heb als programmeur is om eens even goed door de sources van een lib heen te gaan. De Eclipse API (issie weer) bijv.; daar zitten gave patterns in die ik verder nergens heb gezien. Of waar ik nu actief voor ben: http://wicket.sourceforge.net. De initiator van dat project heeft zelf aan AWT en Swing meegewerkt, en dat is duidelijk te zien in de elegantie waarmee hij zaken oplost. Dit is bijvoorbeeld de eerste keer dat ik het Vistitor pattern mooi en praktisch zie toegepast. Daar krijg je zelf ook gewoon weer goeie ideeen van.

ok bron-code is ideaal om dingen te leren.. maar voor het programmeren zelf niet echt. dan gebruik ik toch echt alleen de api.

Vwbt het hercompileren van de java sources... Ik heb het momenteel niet klaarstaan, maar ik heb wel momenten gehad dat ik echt even door de JDK wilde steppen om helder te krijgen hoe bepaalde stukken werken. Bijv. JAAS. Dat werkt best ingewikkeld. Probleem is echter dat de JDK zonder debugging info is gecompileerd, waardoor een hoop variabele informatie etc niet beschikbaar is als je er doorheen stept. Als je dit toch wil doen kun je zelf de JDK hercompileren met debugging info aan. Niet dat je dat dagelijks wil doen... maar het kan.

ik ken JAAS niet.. en zoals ik al zei.. het kan wel handig zijn die java-sources. maar ikzelf doe het neit snel. heb meestal genoeg aan de api.
hercompileren van de jdk vind ik ook niet nodig.. zoals ik al zei debug ik alleen mijn eigen code. uitzonderingen daargelaten.