 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2004How big is the 1.5 JRE download?
How large is the Java 1.5 Runtime Environment download? [ In this specific instance, speaking of the Windows download. ] I have two 1.5 rt.jar's on my system. <jre>/lib/rt.jar 31,971,302 bytes, and.. <sdk>/jre/lib/rt.jar 35,805,012 bytes. OTOH, the JRE 1.5 installer itself, is.. j2re-1_5_0-beta-windows-i586.exe 14,445,056 bytes. How can the installer be less than half the size of the rt.jar alone? What have I missed?  SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > How can the installer be less than > half the size of the rt.jar alone? "Compression"? -Paul >> How can the installer be less than half the size of the rt.jar alone? > > "Compression"? > > -Paul Indeed, that is the answer... But you have to be a bit more precise. Jar files are Zip files, which means they are, in fact, compressed already. So just offering "compression" as a magic answer is wrong. The problem is that zip isn't a very good compression scheme for .class files. It doesn't take advantage of their structure and common idioms effectively, and yeilds suboptimal results. MUCH better compression algorithms, specificly for .class files, have been created. One of those algorithms is used to package the .class files for the JRE download. Part of the install process is extracting those .class files and converting them into jar files. > The problem is that zip isn't a very good compression scheme for .class > files. It doesn't take advantage of their structure and common idioms [quoted text clipped - 3 lines] > download. Part of the install process is extracting those .class files > and converting them into jar files. It is too bad that such compression is not used for Java archives. Microsoft's CAB files do considerably better than JAR files, but CAB files do not seem to do nearly as well as the JRE download seems to do. >>> How can the installer be less than half the size of the rt.jar alone? >> [quoted text clipped - 6 lines] > Jar files are Zip files, which means they are, in fact, compressed > already. Not necessarily. > The problem is that zip isn't a very good compression scheme for .class > files. It doesn't take advantage of their structure and common idioms > effectively, and yeilds suboptimal results. MUCH better compression > algorithms, specificly for .class files, have been created. One of > those algorithms is used to package the .class files for the JRE > download. Can you back that up somehow? I severely doubt that there's all that much difference in performance between such specialized compression schemes and ZIP's general entropy encoding which is *quite* good at compressing the kind of simple redundancies likely to turn up in any kind of executable. Fact is, rt.jar is NOT compressed, probably to speed up startup times. This alone is perfectly sufficient to explain the size difference. > Can you back that up somehow? I severely doubt that there's all that much > difference in performance between such specialized compression schemes and [quoted text clipped - 3 lines] > Fact is, rt.jar is NOT compressed, probably to speed up startup times. > This alone is perfectly sufficient to explain the size difference. Too bad. It would been nice to have proof of a fabulous compression method. But the point does remain that CAB files are substantially smaller than JAR files, and some additional saving can be achieved using obfuscator programs, so it does seem there is room for improvement on Java archive compression. > Too bad. It would been nice to have proof of a fabulous compression > method. But the point does remain that CAB files are substantially > smaller than JAR files[...] Do CAB files support random access to their consituents ? I don't know myself, but part of the reason for JAR file compression not being optimal is that each file is compressed (if at all) independently. (As is familar to old UNIX hackers -- it's much better to compress a tar file, than to tar a collection of individually compressed files) Also the compressor used for each file is "naive" in that it has not been pre-trained on the bit patterns that tend to occur in .class files[*]. There has been a fair amount of work on making JAR-like files smaller, I don't have references to hand just now but I can find them tomorrow if anyone's interested. -- chris [*] It'd be the work of a few minutes to test the effect of pre-training, I may try that tomorrow too... > I don't know myself, but part of the reason for JAR file compression not being > optimal is that each file is compressed (if at all) independently. Aha! That was something I had always suspected about Zip compression algorithms. But then, could you not deliver the 'index' of common parts before the delivery of the first compressed entry? ..though that might represent 30% of the file entire file, sigh.. :-( SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > > Can you back that up somehow? I severely doubt that there's all that much > > difference in performance between such specialized compression schemes and > > ZIP's general entropy encoding which is *quite* good at compressing the > > kind of simple redundancies likely to turn up in any kind of executable. [] > Too bad. It would been nice to have proof of a fabulous compression method. > But the point does remain that CAB files are substantially smaller than JAR > files, and some additional saving can be achieved using obfuscator programs, > so it does seem there is room for improvement on Java archive compression. Well, one disadvantage (in regard to achievable compression, advantage in regard to data safety) of the ZIP/JAR format is that files are compressed independently, so it can't eliminate inter-file-redundancy. And of course there are better entropy compression algorithms. But these factors will usually not result in truly "fabulous" differences. As for obfuscators, you can't count those because they DESTROY information - a kind of lossy compression if you will. > As for obfuscators, you can't count those because they DESTROY > information - a kind of lossy compression if you will. If an obfuscator replaces a class name such as "SignInJustInTimePanel" with an obfuscated name such as "qw" does that destroy anything of importance to the user? > If an obfuscator replaces a class name such as "SignInJustInTimePanel" > with an obfuscated name such as "qw" does that destroy anything of > importance to the user? Only if the class is never used as a component in another application. Obfuscators should only be applied to end-user applications. SignaturePaul Lutus http://www.arachnoid.com > Only if the class is never used as a component in another application. > Obfuscators should only be applied to end-user applications. Obfuscators allow you to exclude particular class names from obfuscation. It would be good to tie obfuscation to the public / private designations within Java. I don't know whether existing obfuscators do this. >>As for obfuscators, you can't count those because they DESTROY >>information - a kind of lossy compression if you will. > > If an obfuscator replaces a class name such as "SignInJustInTimePanel" with > an obfuscated name such as "qw" does that destroy anything of importance to > the user? If the user just wants tu run the code as is, no. But it's information (important, for example, if the user wanted to call those classes from his own code), and it's gone. That's why I compared it to lossy compression. > Fact is, rt.jar is NOT compressed rt.jar is a Zip archive for both v1.4.2 and 1.5.0b2 on my system. > > Fact is, rt.jar is NOT compressed > > rt.jar is a Zip archive for both v1.4.2 and 1.5.0b2 on my system. An UNCOMPRESSED Zip archive. >> > Fact is, rt.jar is NOT compressed >> >> rt.jar is a Zip archive for both v1.4.2 and 1.5.0b2 on my system. > > An UNCOMPRESSED Zip archive. I forgot about that possibility, and you're of course correct. > Fact is, rt.jar is NOT compressed, probably to speed up startup times. > This alone is perfectly sufficient to explain the size difference. Has anyone here ever tested the effect on startup time ? Never got around to it myself, but my /guess/ would be that compression would make it better -- less IO needed, though it is probably OS/FS-dependent. -- chris >> Fact is, rt.jar is NOT compressed, probably to speed up startup times. >> This alone is perfectly sufficient to explain the size difference. [quoted text clipped - 3 lines] > Never got around to it myself, but my /guess/ would be that compression would > make it better -- less IO needed, though it is probably OS/FS-dependent. I'd have to agree with Michael. What possible advantage is there to loading a Zip file with uncompressed files if it is not speed? There was at least a three times size reductuion with standard Zip compression, a saving of some 20 Meg of disk space. If compressed files were actually faster as well, I cannot believe Sun would be so silly as to not do it. Of course, a test case blows the entire philosophising out of the water. Anybody..? SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > There was at least a three times size reductuion > with standard Zip compression, a saving of some > 20 Meg of disk space. It just occured to me that the '9 Meg' I quoted for the compressed file is wrong.. I compressed the *entire* zip file, rather than each entry inside it. Given what you were saying about how each file has it's own self contained expansion instructions/patterns (words to that effect), compressing a single big file structure represented in a zip *should* be more efficient than compressing the same files individually. Bottom line, I would expect that 'each entry compressed individually' would result in a significantly larger final archive file. OK ..stuff expectaions, here is my test.. The file in question is the 1.5 rt.jar Form Size ---- ---- Disk (extracted): 29,873,493 Zip Uncompressed: 31,971,302 Zip Each entry: 15,279,773 Zip Entire file: 9,693,680 Or, to put that another, more visual way.. <http://www.physci.org/test/graph/index.jsp?nm=Zip+Compression+on+Java+1.5+Core+c lass+files+%28units+in+100Kb%29&lbl=Disk+None+Each+All&val=299+320+153+97&width= 70> SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > The file in question is the 1.5 rt.jar > [quoted text clipped - 4 lines] > Zip Each entry: 15,279,773 > Zip Entire file: 9,693,680 I tried the test that I mentioned yesterday: compressing each .class files with a compressor that had been pre-trained with "typical" class file contents. That should allow the compressor to work better since its dictionary is already populated with common sub-strings, and so avoid much of the "warm-up" overhead of separate compression. I'm using the rt.jar from the Windows 1.4.2 JDK. Size without compression: 26,380,124 Size compressing all and only the .class files with maximum compression: 13,532,241 Size compressing the .class files pre-trained with the data from java/lang/String.class 12,703,747 (Using java/lang/Object.class and java/lang/Class.class as training instead: 12,772,088 12,535,712 so the choice of trainer doesn't seem to make much difference.) Which suggests that the loss caused by independent compression of the .class files is not really all that great. Certainly, /I/ wouldn't bother adding the complexity of training to the JAR file format on the basis of these figures. -- chris > Form Size > ---- ---- > Disk (extracted): 29,873,493 > Zip Uncompressed: 31,971,302 > Zip Each entry: 15,279,773 > Zip Entire file: 9,693,680 Here are some figures for the various compression utilities/techniques applied to rt.jar (C:\Program Files\Java\jre1.5.0\lib\rt.jar). I've used Cygwin's zip, gzip and bzip2 using their option for the best compression, and compared with pack200 of J2SE 5.0. Pack200 by default compresses output using gzip, the option -g prevents this. command file size (bytes) relative ------- ---- ------------ -------- rt.jar 33,348,378 100 % zip -9 rt.jar.zip 10,063,673 30.18 % gzip --best rt.jar.gz 10,063,554 30.18 % pack200 -g rt.jar.pack 9,875,459 29.61 % bzip2 --best rt.jar.bz2 8,234,905 24.69 % pack200 rt.jar.pack.gz 4,397,016 13.19 % pack200 on its own (no gzip) does slightly better than zip and gzip. This was also the case when I tried it on rt.jar of jre1.4.2 (also similar relative size figures). I've also compressed an *uncompressed* zip file containing text files (source of Unix file(1) utility): command file size (bytes) relative ------- ---- ------------ -------- file-4.10.zip 1,479,766 100 % pack200 -g file-4.10.zip.pack 1,443,237 97.53 % zip -9 file-4.10.zip.zip 370,410 25.03 % gzip --best file-4.10.zip.gz 370,284 25.02 % pack200 file-4.10.zip.pack.gz 358,737 24.24 % bzip2 --best file-4.10.zip.bz2 317,013 21.42 % Pack200 -g gives a poor result on this zip file (with text files), but it seems to do quite a good job on compressing class files. SignatureRegards, Z. > I've used Cygwin's zip, gzip and bzip2 using their option for the best compression, and compared > with pack200 of J2SE 5.0. Pack200 by default compresses output using gzip, the option -g prevents this. > > command file size (bytes) relative > ------- ---- ------------ -------- ... graphed as.. <http://www.physci.org/test/graph/index.jsp?nm=Compresion+delivered+on+J2SE+5.0+% 28100+Kb%29&lbl=None+zip-9+gzip-best+pack200-g+bzip2-best+pack200&val=333+101+10 1+99+82+43&width=50> > I've also compressed an *uncompressed* zip file containing text files (source of Unix file(1) utility): > > command file size (bytes) relative ..and, <http://www.physci.org/test/graph/index.jsp?nm=Compresion+delivered+on+source+as+ text+files+%28100+Kb%29&lbl=None+pack200-g+zip-9+gzip-best+pack200+bzip2-best+&v al=148+144+37+37+36+32&width=50> Now that's better.. I find a visual aid very helpful, don't you? ;-) SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > <http://www.physci.org/test/graph/index.jsp?nm=Compresion+delivered+on+source+as+ text+files+%28100+Kb%29&lbl=None+pack200-g+zip-9+gzip-best+pack200+bzip2-best+&v al=148+144+37+37+36+32&width=50> Andrew, there's something wrong with the images. For instance, I can't see http://www.physci.org/test/graph/white.png in my browser. Maybe your protection against hotlinking? SignatureRegards, Z. >> <http://www.physci.org/test/graph/index.jsp?nm=Compresion+delivered+on+source+as+ text+files+%28100+Kb%29&lbl=None+pack200-g+zip-9+gzip-best+pack200+bzip2-best+&v al=148+144+37+37+36+32&width=50> > [quoted text clipped - 3 lines] > > Maybe your protection against hotlinking? Please disregard. I probably is your check for 'referer', but in my browser (Mozilla) I had set an option for 'not sending referer' [exactly for the same reason for sites that check referer; you probably check 'if referer notEquals "www.physci.org" then don't serve image' ] Reset the option, now it's OK. SignatureRegards, Z. > I probably is your check for 'referer', but in my browser > (Mozilla) I had set an option for 'not sending referer' Aaah.. I had presumed you had made a 'direct request' for the image, though I could ..not for the life of me, figure *why*.. This 'not send referrer' is bad news.., yet another pitfall we web-designers have to face in trying to deliver content to our visitors. (sigh) > Reset the option, now it's OK. Thanks for reporting back. .. Now I have to figure what to do for others that might have that setting, as it would affect a lot of things around the site, and I simply cannot afford to lift the hotlink protection. SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > Thanks for reporting back. .. You're welcome; after all, it was a problem on my side. > Now I have to figure what to do for others > that might have that setting, It is quite a specific setting, and I don't think a lot of people are aware of it or even have it enabled. I don't know which browsers other than Mozilla have this option for sending/not sending the referer. In Mozilla (including Firefox and the ones based on same code, e.g. Netscape, Safari) it's more or less a hidden option: it's not available in Mozilla's configuration window, but you can change it by editing the config preferences. A laymen user of Mozilla probably will have no trouble with your site. Maybe you could place a footnote on the page (or a bigger message on your homepage) stating that the browser must send a HTTP referer header or otherwise the page doesn't display properly. > as it would affect > a lot of things around the site, It sure does: after I changed the option, your site was much more colourful ;-) > and I simply > cannot afford to lift the hotlink protection. I can understand that. SignatureRegards, Z. > A laymen user of Mozilla probably will have no trouble > with your site. Whew! > Maybe you could place a footnote on the page (or a bigger message on your homepage) stating that the > browser must send a HTTP referer header or otherwise the page doesn't display properly. (shakes head sadly) If your browser supports Java these pages offer extra funcionality. If your broswer was not so broken I could float elements, and would not have to hide everything invented this millinium from it. If your monitor were not so damn small and stingy I could bathe this screen in swathes of glorious color. ...... At what point does the user shrug and say 'stuff this site, I'm off somewhere nice.' It is very difficult to inform a user of their defective browser/OS/Java usage or lack-thereof.. without offending them. ..Or maybe it's just the way I say it. ;-) SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > It is very difficult to inform a user of their > defective browser/OS/Java usage or lack-thereof.. > without offending them. ..Or maybe it's just the > way I say it. ;-) Was it something like "Error: one bad user found in front of screen" or "UBNC (user brain not connected)" ;-) SignatureRegards, Z. > Andrew, there's something wrong with the images. For instance, I can't see > http://www.physci.org/test/graph/white.png > in my browser. ...errrm. Can you see it within the graph in the page? > Maybe your protection against hotlinking? Well.. probably. I noticed my bandwidth had quadrupled over a three month period while page hits were actually trailing off. Actually, the graph says it better.. <http://www.athompson.info/andrew/hotlink.jsp> I had to take some radical measures that I am still untwining the curlier file types from. But I can see no compelling reason to remove the hotlink protection from the images if they display correctly in the pages though. So I suppose I disagree with your assessment of 'something wrong', if I understand correctly. OTOH, it is just a 1x1 white image, you want me to post it to you? Heck, ..I'll even throw in the other colors for free! ;-) SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > There was at least a three times size reductuion > with standard Zip compression, a saving of some > 20 Meg of disk space. If compressed files were > actually faster as well, I cannot believe Sun > would be so silly as to not do it. Oh, my boy, my boy... It is time you left this world of make-believe behind. /Of course/ Sun could be that silly... (I'm not saying they /are/, mind, but the certainly could.) Cynicism aside, another reason might be to avoid having to duplicate the relatively complicated code for JAR file reading in the initial class loader (which couldn't use the "normal" java.util.zip stuff during bootstrapping). -- chris > It is time you left this world of make-believe behind. ..ehh (shrugs), it has pretty colors. SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > Cynicism aside, another reason might be to avoid having to duplicate the > relatively complicated code for JAR file reading in the initial class loader > (which couldn't use the "normal" java.util.zip stuff during bootstrapping). Not so quick! ..I recalled something Zoopy mentioned (couldn't be bothered Googling, so I'll quote) "In 1.5/5.0 they additionally speed up class-loading by something called class data sharing (<http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html>). In the jre1.5*/bin/client directory you'll find a "classes.jsa" file (Java Shared Archive) which apparently contains an internal representation of the core classes." And guess which two packages are extensively mentioned in the classes.jsa file? (I just dumped the entire 12 Meg into trusty little TextPad and did a 'find'..) java.util.zip and java.util.jar are mentioned extensively, whereas java.beans.XMLEncoder* is not, nor is any of the CORBA* stuff (*just to check Sun did not also store a representation of the ZipEntries of the main rt.jar in it, and since I couln't be bothered trying to decipher Sun specs at this time in my temporal day..). So.. your other reason was... > /Of course/ Sun could be that silly. ...hmmmm. Yes they *could* be that silly, but it is a ..flimsy premise without further information to support it. [ So there! :-P Oh and ..loving these *colors*, wish you were here! ;-) ] SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology >>> How can the installer be less than half the size of the rt.jar alone? >> [quoted text clipped - 14 lines] > download. Part of the install process is extracting those .class files > and converting them into jar files. You're probably referring to Pack200. Qouting from JSR200 <http://jcp.org/en/jsr/detail?id=200>: "The JavaTM archive format can compress these classes at the byte level only, leading to a meager reduction factor of about two. We need to compress the classes much more efficiently, thus making network transfers faster and therefore more reliable." "An example of a more effective compression technology is the Pack format which was developed to reduce the download size of the JRE (J2SE Runtime Environment) installer for windows in J2SE v1.4.1 and J2SE1.4.2. The Pack format simultaneously organizes the layout of all classes and resource files within a JAR, removing repetitions of shared structures, and yielding a reduction factor of seven to nine." Tools for Pack200 are now part of J2SE 5.0: <http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#deployment> SignatureRegards, Z. > You're probably referring to Pack200. Nuh. I have now checked the 1.3.1 jar as well, not one iota of compression used, it is simply a big file archive. Whatever compression techniques Sun is offering, or planning to offer developers, they are not applying them to their own rt.jar's. SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology >>You're probably referring to Pack200. > [quoted text clipped - 5 lines] > or planning to offer developers, they are not > applying them to their own rt.jar's. You must have misinterpreted to whom I was replying: it wasn't you ;-) but Carl Howells, specifically to his line: "MUCH better compression algorithms, specificly for .class files, have been created" SignatureRegards, Z. >> You're probably referring to Pack200. > > Nuh. .. Though if you rename the 1.5 rt.jar to a .zip and open it, WinZip pops up a 'comment' saying simply 'PACK200'.. It still lists the 'File compression ratio' as a fat 0% though. SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology >>>You're probably referring to Pack200. >> [quoted text clipped - 4 lines] > saying simply 'PACK200'.. It still lists > the 'File compression ratio' as a fat 0% though. Yep, see that comment too. Of all the rt.jar files still hanging around on my system (1.3.0/1, 1.4.0/1/2, 1.5.0), none of them is compressed. I've always assumed this was to speed up class-loading. In 1.5/5.0 they additionally speed up class-loading by something called class data sharing (<http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html>). In the jre1.5*/bin/client directory you'll find a "classes.jsa" file (Java Shared Archive) which apparently contains an internal representation of the core classes. SignatureRegards, Z. ... > In 1.5/5.0 they additionally speed up class-loading by something called class data sharing > (<http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html>). > In the jre1.5*/bin/client directory you'll find a "classes.jsa" file (Java Shared Archive) which > apparently contains an internal representation of the core classes. Holy Crap! At 12,058,624 bytes, it is ironic that the file to 'speed up' 1.5 is larger than the entire 1.3.1 core classes (11,646,454).. SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > ... >> In 1.5/5.0 they additionally speed up class-loading by something called [quoted text clipped - 7 lines] > the file to 'speed up' 1.5 is larger than the entire > 1.3.1 core classes (11,646,454).. That's probably not so surprising since the core library has grown quite a lot since the 1.3 days. And the file only gets created during installation (or via a switch in the java command) anyway. SignatureKind regards, Christophe Vanfleteren > That's probably not so surprising since the core library has grown quite a > lot since the 1.3 days. The problem here, Christophe, is that your letting the truth get in the way of a good story. ;-) SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology >> How can the installer be less than >> half the size of the rt.jar alone? > > "Compression"? (slaps forehead) That is what you (..OK, I) get for assuming Sun stored the rt.jar as a compressed file. [ It reduces to 9,808,537 bytes with compression. ] Well.. that was embarrassing but informative. Thanks Paul! I can continue slagging .NET for being a 27 Meg download, ..though I'll have to wade through over 60 Meg of 'critical updates' before I can even get to check that, apparently.. :-( SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.