Discussions

News: Davanum Srinivas: Why bundling JAX-WS in Java6 was a bad idea!

  1. Davanum Srinivas, in "Why bundling JAX-WS in Java6 was a bad idea!," points out that bundling JAX-WS means that updating the web services API to have new features or bug fixes involves actually patching the runtime environment - or still resorting to external libraries.
    Welcome to the real world!
    This isn't just an expression of frustration from one person. Web services are important for Java, but implementations vary widely. It makes sense to have them in Java as a standard, but how good is the current implementation? If developers still have to replace the built-in version in order to get what should be considered normal features, is the standard worth having?

    Threaded Messages (117)

  2. The inherent problem with JAX-WS is that it encourages a bottom-up approach to build a web service. That is, develop a java class first and then develop the WSDL (contract). A contract-first style (WSDL and schemas first) provides the best chance for interoperability especially when the technologies and platforms are different on both ends of the wire. Developing schemas first encourages an interface-based design approach that will provide the maximum reuse and interoperability. Hence, I agree with the author that bundling JAX-WS with Java 6 is a bad idea but for a different reason than his.
  3. A contract-first style (WSDL and schemas first) provides the best chance for interoperability especially when the technologies and platforms are different on both ends of the wire. Developing schemas first encourages an interface-based design approach that will provide the maximum reuse and interoperability.
    Yes, but if WSDL would have been nicer interface definition language :), instead of cryptic bloat. Schema is better looking though.
  4. Agree[ Go to top ]

    I'm working with Oracle BPEL and I have had some interoperability problems with my java-based WS. Thus I should had under my complete control the wsdl file and the wsd used to communicate with BPEL. Hence, WSDL (contract) first development approach is better than class first approach. It is clear that wsdl grammar is not easy to understand, but on the other hand, is not so cryptic. I think that a short "hard-study first approach" to understand wsdl and wsd grammar is useful when you have to work seriously with WS. If you have to implement only a simple "HelloWorld" service, you can use the java-class approach.
  5. I am very glad to see three people 'getting' that created web services from Java classes is a bad idea. I've said this in the past and been met with all kinds of doubt and dismissal. The WSDL standard we all know and hate is very bad. WSDL 2.0 is a lot better. Hopefully it will be adopted quickly because the old spec has really been a stumbling block in building web services. It worked with two tools from the same vendor which could not understand the WSLDs created by the other. This seems crazy but it's understandable when you look at how stupidly redundant the spec is.
  6. Recall that WSDL needs to be focused in describing the service, that works with messages. For a Java developer that only knows about objects and method calls with parameters, WSDL was not at all suitable due to the impedance mismatch found in the concepts. WS is to create services that will interact with aliens (could those aliens speak English is another story), not to expose Java classes. I'm having a hard time in Univesity to teach my students that difference! Going back to original discussion, as a partner said, incorporating a stack to the JDK seems like a move to solve often heard critic about .NET having all-included and Java being a Frankestein made up of pieces. .NET has its own concept of WS as RPC packed into an XML document. Please, let us not go into that. William Martinez Pomares
  7. Recall that WSDL needs to be focused in describing the service, that works with messages. For a Java developer that only knows about objects and method calls with parameters, WSDL was not at all suitable due to the impedance mismatch found in the concepts.
    That's not really the with WSDL that I am referring to. The problem with the original WSDL spec is that there are separate sections of the document with different structures that contain the exact same information! (hopefully) From what I understand this was done only as a compromise between members of the consortium that created the recommendation. They couldn't agree on one way so they put two ways in there. This creates a situation where one vendor can create a WSDL with all the required information but doesn't create the redundant section properly. Another vendor does the same thing but reverses the sections. This means they can't talk. If you think this is not really happening, I assure you that it is. I've had to deal with it in real life (and real money) situations. WSDL 2, from what I can tell, removes the redundancy and is much cleaner (i.e. easier to read) in general.
  8. James, believe me I believe you! WSDL 2 may solve the redundancy problem (which is actually a technical one), and may be even more deterministic, but if it still encourages people to think in WS as an exposing technology, it will suffer from interop problems too, but in a higher level of abstraction! So, let's solve WSDL first, and then the developers minds :-). BTW, I also agree that JRE should be a core, JDK may contain standard libraries we can use or ignore. William Martinez Pomares.
  9. James, believe me I believe you!

    WSDL 2 may solve the redundancy problem (which is actually a technical one), and may be even more deterministic, but if it still encourages people to think in WS as an exposing technology, it will suffer from interop problems too, but in a higher level of abstraction!
    I completely agree but I don't think that WSDL is doing this. I think it's all the tool kits that take a class an expose it as a web service. This form of 'design by proxy' suffers from all kinds of problems, especially vendor lock-in. It's an easy way to create a web service to be sure but it suffers from the problems you are describing. There's a big shift towards service oriented architecture and I think WS-* and SOAP aren't necessarily going to end up being the standards of choice. Getting developers to think in terms of services is a challenge. Ironically, the 'dinosaurs' doing EDI have a lot of experience in this 'new' arena.
  10. You are right! Lazy developers and the "right click" syndrome!
  11. Bundling JAX-WS in Java6, fantastic!![ Go to top ]

    The inherent problem with JAX-WS is that it encourages a bottom-up approach to build a web service. That is, develop a java class first and then develop the WSDL (contract). A contract-first style (WSDL and schemas first) provides the best chance for interoperability especially when the technologies and platforms are different on both ends of the wire. Developing schemas first encourages an interface-based design approach that will provide the maximum reuse and interoperability.

    Hence, I agree with the author that bundling JAX-WS with Java 6 is a bad idea but for a different reason than his.
    I have to say I completely agree with the contract/XSD/WSDL first approach. Ive used JAX-WS extensively. JAX-WS has great support for contract first web service development. Calling web services should be 'out of the box' in any language or runtime, its great to see a standard for this in Java.
  12. Not that bad...[ Go to top ]

    Adding -Djava.endorsed.dirs=$JAXWS_HOME/lib seems not that hard to me.
  13. It actually makes sense for the runtime to use something like JAX-WS to make WS more native. The problem is that the concept of a native WS doesn't make sense!. JAX-RPC had the legacy RPC concept in the name, and RPC is actually a coupling concept that ties to the development platform, language, paradigm, and makes interop very hard! JAX-WS is not escaping from this. The bottom-up WS creation contains the inherent RPC concept, an illness present in the majority of developers. Now, let's think the bundled stack is not JAX-WS. Are we still talking of a native WS? Or should we look at it as a simple add-on library that has nothing to do with the language itself? I think it is less intrusive, if you compare it with the idea of incorporating WS directly to the language. Do you recall the XML-in-Java idea of making XML a native type? Anyway, you can always use your favorite stack. William Martinez Pomares.
  14. Too much bundling in general is the problem with Java. There is so much crap in the JDK that can't seriously be considered core functionality. It's been like this from early on. This is one serious offender. If you can't manage to download a jar and tie it into your deployment, what chance do you have of creating successful web services?
  15. If you can't manage to download a jar and tie it into your deployment, what chance do you have of creating successful web services?
    I think they should only release the JDK as source code. If you can't manage to compile your own JDK then what chance do you have of creating a successful web service? I think it is a good idea that intelligent defaults are bundled with the JDK and then you are given the ability to override them. That being said I'm not arguing that JAX-WS is the best default, but I think the idea of providing an out of the box default is a good one. I just want to develop applications, and I don't want to play puzzle with JAR files before I start each app.
  16. If you can't manage to download a jar and tie it into your deployment, what chance do you have of creating successful web services?


    I think they should only release the JDK as source code. If you can't manage to compile your own JDK then what chance do you have of creating a successful web service?
    That's a flawed analogy. Downloading a jar and using it as part of a deployment is trivial. If you aren't a complete incompetent, your web service is going to be deployed using one or more jars anyway. And realize that this jar wouldn't be needed to make use of the web service, just to access it. Basically you are saying that you don't think about what tools you are going to use. You just use whatever is at hand. If you need to drive a screw and you've got a hammer handy, pound away, right?
  17. And realize that this jar wouldn't be needed to make use of the web service, just to access it.
    I meant 'just to create it'. And maybe that's not right. I'm not sure whether they help with calling the web service. That's something I could see bundling with the JDK. But to bundle a library for creating a web service is just plain wrong IMO.
  18. .NET[ Go to top ]

    May be because competition with .NET stack. Java JVM must include everything to look competitive
  19. I think you are correct, sir ![ Go to top ]

    May be because competition with .NET stack. Java JVM must include everything to look competitive
    Yup. There are two odd things going on in this thread IMO : 1- the fact that this competitive reason is mentioned by only one person 2- the idea that Web Services are outside the baseline capabilities of a development platform. 1 is a very good reason and in fact I need to hear no more. 2 is something for Java folks to ponder : 'the network IS the computer', after all ... have we lost the conceptual lead, the visionary hope that made Java liberating in the first place ?
  20. Re: I think you are correct, sir ![ Go to top ]

    Ethan. 1. Count again, I mentioned that in one of my first comments in the thread. 2. Look at the native idea. Look at history. Web Services concept was born as an architecture, a conceptual idea. Making it native is to jump down to convert into an idiom!. History tells us that the idea came, and vendors took disparate technologies that may fit together, created some wrapping, a bow on top and voila! Performance dropdowns, complexity, interop problems. Java may take the lead and convert a glued Frankie into a brilliant solution. William Martinez Pomares
  21. ...[ Go to top ]

    Ethan.
    1. Count again, I mentioned that in one of my first comments in the thread.
    2.
    OK. I read that as a concern about a 'Frankenstein' archiecture rather than an acceptance of competitive reality.
    Look at the native idea. Look at history. Web Services concept was born as an architecture, a conceptual idea. Making it native is to jump down to convert into an idiom!. History tells us that the idea came, and vendors took disparate technologies that may fit together, created some wrapping, a bow on top and voila! Performance dropdowns, complexity, interop problems. Java may take the lead and convert a glued Frankie into a brilliant solution ...
    Yeah ... 'may'. Or maybe not ... it's not like the need hasn't been painfully obvious for a long time. I needed generics a lot less than I needed a usable Web Services development tookit, and I sure as Hell didn't need scripting language support at all. Where's the vision these days ? At the moment the entire Java community is playing catchup with Microsoft on the Web Services front. I guess I'm just trying to prod the community here a little bit - it's time to understand that Web Services are as basic as JDBC. Sometimes it feels like the entire Java development world has spent the last three years building endless variations of logging applications and Web frameworks over and over again ... thinking back to 1995-96 when Sun and the mysterious OO language called 'Java' blew open the Internet and the competitive IT landscape, I feel that something somewhere has been lost. Meh.
  22. Re: ...[ Go to top ]

    At the moment the entire Java community is playing catchup with Microsoft on the Web Services front. I guess I'm just trying to prod the community here a little bit - it's time to understand that Web Services are as basic as JDBC.

    Sometimes it feels like the entire Java development world has spent the last three years building endless variations of logging applications and Web frameworks over and over again ... thinking back to 1995-96 when Sun and the mysterious OO language called 'Java' blew open the Internet and the competitive IT landscape, I feel that something somewhere has been lost.

    Meh.
    Totally agree! Is WS buzzword driving commercial decisions? I recall a phrase about the freedom of thinking lost when that thinking leads to ideas you can buy. Sad.
  23. Re: .NET[ Go to top ]

    May be because competition with .NET stack. Java JVM must include everything to look competitive
    .NET CLR does not include WS.
  24. Re: .NET[ Go to top ]

    May be because competition with .NET stack. Java JVM must include everything to look competitive


    .NET CLR does not include WS.
    pssst. George. We're talking the .Net STACK. What you get when you launch an app on a Windows box that has .Net installed. mmmmmmkay? mmmkay.
  25. Re: .NET[ Go to top ]

    We're talking the .Net STACK.
    The problem is that people are talking about Java JVM, not the Java EE stack.
  26. Re: .NET[ Go to top ]

    We're talking the .Net STACK.


    The problem is that people are talking about Java JVM, not the Java EE stack.
    No, we are talking about the JRE (and what is bundled with it), not the JVM.
  27. Re: .NET[ Go to top ]

    Btw., in .NET world you too need to install WSE (Web Services Enhancements) to get support for latest and greatest (?!?) WS standards. So having to override existing JAX-WS 2.0 implementation in Java SE 6 with JAX-WS 2.0.1 or 2.1 is not a big deal (actually it's natural in todays environment), it just has to be well documented. P.S. Installing JAX-WS 2.0.1 on a top of Java SE 6 is much faster then WSE 3.0 on a top of .NET 2.0 ;)
  28. Re: .NET[ Go to top ]

    What you get when you launch an app on a Windows box that has .Net installed.
    What will you get when you launch an app on a RedHat Linux that has JBoss installed?
  29. That's a flawed analogy.
    Well obviously, I was being sarcastic. I still don't understand why some developers are against reasonable defaults? Once again I'm not saying that JAX-WS it the right default. I just don't agree with the idea that developers should have to play puzzle with jar files before they start an application. I think it makes sense to start with a complete a base as possible and then override or substitute jars where needed (for a specific requirement) or desired (for personal preference). I have no problem sorting out my own jar files, and determining what I need or what, but many who are new to java do. I think that anything we can do to lower the barrier to entry for java will help java in the long run.
  30. That's a flawed analogy.


    Well obviously, I was being sarcastic. I and that's why I responded that your analogy was flawed.
    I still don't understand why some developers are against reasonable defaults?
    I'm not against reasonable defaults. I'm against unreasonable defaults. The 1.5 JRE on my machine is over 77MB. Java 6, from what I understand is even bigger. The other problem is that with so many classes in the JDK, it's impossible to keep track of all of them. There may be things in the JDK that would be very useful to me but I won't know about it because there's just too much to take in. Lastly, putting something like this in the JDK kills competition in the OS space. Yes, MS developers have the luxury of not having to make any decisions but that path leads to stagnation and decay.
  31. The 1.5 JRE on my machine is over 77MB. Java 6, from what I understand is even bigger. Why is this an issue? Even on the smallest home PC it is hard to find less than 40GB of storage. That means the 1.5 JRE takes up around 0.2% of disk space.....
  32. The 1.5 JRE on my machine is over 77MB. Java 6, from what I understand is even bigger.

    Why is this an issue? Even on the smallest home PC it is hard to find less than 40GB of storage. That means the 1.5 JRE takes up around 0.2% of disk space.....
    It's not the space, it's the time it takes to get and install. For a developer, it's no problem, but for a user, having to install a huge application suite to run an applet on a page isn't very appealing. In any event, why carry around all this unnecessary baggage? I'd wager you could remove at least a third of the packages in the JDK without any impact to most Java applications. I don't see why it would be so hard to split this up into digestible pieces and provide an automatic package installer in the JRE.
  33. It's not the space, it's the time it takes to get and install. For a developer, it's no problem, but for a user, having to install a huge application suite to run an applet on a page isn't very appealing. In any event, why carry around all this unnecessary baggage? I'd wager you could remove at least a third of the packages in the JDK without any impact to most Java applications.

    I don't see why it would be so hard to split this up into digestible pieces and provide an automatic package installer in the JRE.
    I don't see time to get or install as an issue either - I can download the Windows JRE in just a few minutes even on a relatively poor bandwidth broadband connection. With the GPL-ing of Java, many more systems and applications will have the JRE bundled anyway. The advantage of having a single download is that it isn't an application suite. Sure, you could probably remove a third - but which third? That is where the disagreement will arise. Indeed, I would like more included in the base install for my use - the Advanced Imaging API for example. The problem with an automatic package installer is that they can go wrong, leaving systems in an inconsistent state. The examples of this kind of thing being used in in other situations (like Linux package managers) does not bode well. We are talking here about the kind of thing that system admins are expected to deal with, not end users. The evidence suggests, at least to me, that splitting up this kind of thing can be hard, especially when some of what you might want to split off (Swing perhaps?) involves platform-specific binaries.
  34. I don't see time to get or install as an issue either - I can download the Windows JRE in just a few minutes even on a relatively poor bandwidth broadband connection.
    Not everyone has a broadband connection.
    With the GPL-ing of Java, many more systems and applications will have the JRE bundled anyway.
    Worthless. I learned long ago you can't trust the user's JRE. The only truly safe way to deliver a Java application is to bundle the JRE into your install files. Otherwise the user ends up dealing with classpath and version issues And we are back to the space issue. It's really the lack of a good package and version manager that makes this necessary.
    The advantage of having a single download is that it isn't an application suite. Sure, you could probably remove a third - but which third?
    We could remove CORBA, Swing, AWT, I could go on for quite a while. Pretty much anything that isn't a core class or utility could be a candidate.
    That is where the disagreement will arise.
    What disagreement? Sun should just do it and stop being idiots about the whole thing.
    Indeed, I would like more included in the base install for my use - the Advanced Imaging API for example.
    Why should you burden everyone else with your needs?
    The problem with an automatic package installer is that they can go wrong, leaving systems in an inconsistent state.
    And the problem with airplanes is that they can crash. I'm not going to even explain why this is a completely fallacious argument because it would be patronizing.
    The examples of this kind of thing being used in in other situations (like Linux package managers) does not bode well.
    I use the Eclipse package installer and it works pretty well as far as I can tell. You are not arguing that a package manager could not be written to work properly are you?
    We are talking here about the kind of thing that system admins are expected to deal with, not end users.
    And that's where 'automatic' comes in. Have you ever installed a plugin or extension into IE or FireFox? That's more complex than what I imagine.
    The evidence suggests, at least to me, that splitting up this kind of thing can be hard, especially when some of what you might want to split off (Swing perhaps?) involves platform-specific binaries.
    Why would that make it harder? You'd get the version of the package you needed. If you are on Windows, you get the Windows version.
  35. Not everyone has a broadband connection
    It still won't take long, and as you say below, you bundle the JRE anyway.
    With the GPL-ing of Java, many more systems and applications will have the JRE bundled anyway.


    Worthless. I learned long ago you can't trust the user's JRE. The only truly safe way to deliver a Java application is to bundle the JRE into your install files.
    Right, so the download time is irrelevant for you.
    Otherwise the user ends up dealing with classpath and version issues And we are back to the space issue. It's really the lack of a good package and version manager that makes this necessary.
    There isn't a space issue. As I described, a single JRE install is a fraction of a percent of even the smallest disk found on a new PC.
    The advantage of having a single download is that it isn't an application suite. Sure, you could probably remove a third - but which third?


    We could remove CORBA, Swing, AWT, I could go on for quite a while. Pretty much anything that isn't a core class or utility could be a candidate.
    That is where the disagreement will arise.


    What disagreement? Sun should just do it and stop being idiots about the whole thing.
    Because a lot of people who need Swing (like me) would disagree with you about it not being core.
    Indeed, I would like more included in the base install for my use - the Advanced Imaging API for example.


    Why should you burden everyone else with your needs?
    Because it isn't a burden - it is tiny.
    The problem with an automatic package installer is that they can go wrong, leaving systems in an inconsistent state.


    And the problem with airplanes is that they can crash. I'm not going to even explain why this is a completely fallacious argument because it would be patronizing.
    It isn't fallacious - I have seen this kind of thing happen often (not plane crashing).
    The examples of this kind of thing being used in in other situations (like Linux package managers) does not bode well.


    I use the Eclipse package installer and it works pretty well as far as I can tell. You are not arguing that a package manager could not be written to work properly are you?
    I am arguing that it is easy to write a package manager for use by system admins and developers that works property almost all of the time, but to write one that may have to handle dozens of different versioned packages that works easily for end users is not so easy, but anyway, I really can't see the point.
    We are talking here about the kind of thing that system admins are expected to deal with, not end users.


    And that's where 'automatic' comes in.
    I have yet to see an automatic one. Even products like Windows Update requires user intervention.
    Have you ever installed a plugin or extension into IE or FireFox? That's more complex than what I imagine.

    The evidence suggests, at least to me, that splitting up this kind of thing can be hard, especially when some of what you might want to split off (Swing perhaps?) involves platform-specific binaries.


    Why would that make it harder? You'd get the version of the package you needed. If you are on Windows, you get the Windows version.
    Sorry, but I think you are plain wrong here. You are mostly talking about things that experienced system admins do, not users (such as using the Eclipse package installer). Also, I have personally had problems with the Eclipse package installer, and with installing plugins or extensions into both IE and Firefox, with incompatibilities and broken connections. The problem with binaries should be plain to anyone who has had to manage the installation of packages composed of multiple binaries and libraries - it introduces system dependencies. At least with a single JRE the dependencies can be defined for everything. But it is possible to imagine a Swing+AWT-free JRE that works fine on a Linux system until the user wants to use Swing, but then this introduces all sorts of new system library dependencies. My concerns about these things are based on personal experience of how this can go badly wrong and make things more difficult for the developer - it is not 'plane crash'-unlikely.
  36. There isn't a space issue. As I described, a single JRE install is a fraction of a percent of even the smallest disk found on a new PC.
    It's a space issue for the install. It bloats what has to be delivered a lot, say 5 times larger for a small application.
    It isn't fallacious - I have seen this kind of thing happen often (not plane crashing).
    It is absolutely fallacious. Your argument is that it's been poorly executed in the past and therefore it isn't feasible. Or that you've seen problems in the past so we'd better not try it. I'm sure you can think of a couple of things that we take for granted that would never have been accomplished if everyone thought this way.
    I am arguing that it is easy to write a package manager for use by system admins and developers that works property almost all of the time, but to write one that may have to handle dozens of different versioned packages that works easily for end users is not so easy, but anyway, I really can't see the point.
    Really? It seems so obvious to me. All you would need is a central certification an directory server cluster (most likely run by sun). It would keep track of trusted sources and provide security in the form of certificates and digests of the different jars. When a developer creates a new application jar, he or she puts a list of the jars needed and the versions. When the user attempts to execute the jar, the jvm checks the installed jars list against the apps requirements, if there are missing jars or versions, the jvm informs the user and asks for whether the jar should be downloaded. The JVM is OS and hardware specific and can therefore request the appropriate binaries, if needed. The application would specify the jars it needed and each applications classpath would be separate from all others.
    We are talking here about the kind of thing that system admins are expected to deal with, not end users.
    I think this would be easier than the classpath and version issues that users are forced to deal in lieu of such a system.
    You are mostly talking about things that experienced system admins do, not users (such as using the Eclipse package installer).
    I don't know any sys-admins that even know what the Eclipse installer is.
    My concerns about these things are based on personal experience of how this can go badly wrong and make things more difficult for the developer - it is not 'plane crash'-unlikely.
    Yes, lets all fear change and refuse to consider that there may be a better way.
  37. There isn't a space issue. As I described, a single JRE install is a fraction of a percent of even the smallest disk found on a new PC.


    It's a space issue for the install. It bloats what has to be delivered a lot, say 5 times larger for a small application.
    Only if every application had to include its own JRE, and even if it did, 15MB is small these days.
    It is absolutely fallacious. Your argument is that it's been poorly executed in the past and therefore it isn't feasible. Or that you've seen problems in the past so we'd better not try it. I'm sure you can think of a couple of things that we take for granted that would never have been accomplished if everyone thought this way.
    I never said it wasn't feasible, I just don't think it is worth the effort. My view is that it is a waste of time, with resources better spent on other things.
    I am arguing that it is easy to write a package manager for use by system admins and developers that works property almost all of the time, but to write one that may have to handle dozens of different versioned packages that works easily for end users is not so easy, but anyway, I really can't see the point.


    Really? It seems so obvious to me.

    All you would need is a central certification an directory server cluster (most likely run by sun). It would keep track of trusted sources and provide security in the form of certificates and digests of the different jars.

    When a developer creates a new application jar, he or she puts a list of the jars needed and the versions. When the user attempts to execute the jar, the jvm checks the installed jars list against the apps requirements, if there are missing jars or versions, the jvm informs the user and asks for whether the jar should be downloaded. The JVM is OS and hardware specific and can therefore request the appropriate binaries, if needed.

    The application would specify the jars it needed and each applications classpath would be separate from all others.
    If it is so obvious, why does it fail when it has been tried by others? Just look at the issues that have arisen with RPM managment or dependencies in Debian distributions. Another matter arises - why should Sun maintain such a repository of modules? Where do open source and other versions of the JRE hold their implementations? What about IBM's JRE, or HPs? Their versions of modules may not be the same, and their implementation of binaries will certainly differ. Also, this would seem to restrict much Java use to those with network connections. At least with the JRE as it is, you can be sure everything is present. And as I explained, requesting the appropriate binaries is not trivial, as that may require in turn upgrades to the OS. I have had to deal with this when upgrading the JRE on Linux. But at least I only had to deal with it once, not possibly each time I installed a component of the JRE.
    I think this would be easier than the classpath and version issues that users are forced to deal in lieu of such a system.
    On the contrary, I think it would introduce yet more version issues - versions of components of the JRE.
    I don't know any sys-admins that even know what the Eclipse installer is.
    Ok, so I should have said 'system admins and developers'. The point is - not end-users.
    My concerns about these things are based on personal experience of how this can go badly wrong and make things more difficult for the developer - it is not 'plane crash'-unlikely.


    Yes, lets all fear change and refuse to consider that there may be a better way.
    I think the appropriate motto here is 'if it ain't (too badly) broke, don't fix it'.
  38. If it is so obvious, why does it fail when it has been tried by others? Just look at the issues that have arisen with RPM managment or dependencies in Debian distributions.
    The problem with these systems and many like it is that they use a global local repository. It's the same reason having a global classpath environment variable causes all kinds of problems. This situation means if you geta new version of one library, you affect anything else that uses it. That's where the issues arise. It's not the manager that's the problem. It's the way the applications are accessing the libraries. In Java there is a solution. First of all, we need to kill the global classpath environment variable thing. That was really shortsighted. Instead, all applications must specify their classpath explicitly. The problem with that has always been that you don't know where the jars are unless you installed them yourself. This solution solves the whole mess. Now, the developer just lists the standard jars needed (with versions). The repository makes sure the required jars are on the system and sets that portion of the applications classpath. The big advantage of this would be that in addition to making the JRE lean, it could be expanded to include things that are not part of the JDK. For example, from what I can tell LOG4J is still more popular than logging api in the JDK. Apache could easily set up a repository for retrieving their libraries reliably and safely. The other advantage would be that this would remove a lot of the impetus for adding everything to the JDK. When a new patch for JAX-WS comes out, it wouldn't be an update to the JRE. Just a new version of the library.
    On the contrary, I think it would introduce yet more version issues - versions of components of the JRE.
    Like what? What version issues would exist that don't already?
    Also, this would seem to restrict much Java use to those with network connections. At least with the JRE as it is, you can be sure everything is present.
    There is nothing about this that would prevent a full install of all standard jars. That would make the most sense for a computer that had no network connection and would be loaded from a disk. Even for a
  39. If it is so obvious, why does it fail when it has been tried by others? Just look at the issues that have arisen with RPM managment or dependencies in Debian distributions.


    The problem with these systems and many like it is that they use a global local repository. It's the same reason having a global classpath environment variable causes all kinds of problems. This situation means if you geta new version of one library, you affect anything else that uses it. That's where the issues arise. It's not the manager that's the problem. It's the way the applications are accessing the libraries.

    In Java there is a solution. First of all, we need to kill the global classpath environment variable thing. That was really shortsighted. Instead, all applications must specify their classpath explicitly. The problem with that has always been that you don't know where the jars are unless you installed them yourself.

    This solution solves the whole mess. Now, the developer just lists the standard jars needed (with versions). The repository makes sure the required jars are on the system and sets that portion of the applications classpath.

    The big advantage of this would be that in addition to making the JRE lean, it could be expanded to include things that are not part of the JDK. For example, from what I can tell LOG4J is still more popular than logging api in the JDK. Apache could easily set up a repository for retrieving their libraries reliably and safely.

    The other advantage would be that this would remove a lot of the impetus for adding everything to the JDK.

    When a new patch for JAX-WS comes out, it wouldn't be an update to the JRE. Just a new version of the library
    Hi James, I think I've found exactly what you're looking for: http://rubygems.org/ Paul.
  40. Hi James,

    I think I've found exactly what you're looking for:

    http://rubygems.org/

    Paul.
    That's great for Ruby but it doesn't help with Java. Having all users install a ruby application is not what I had in mind. For this to be really effective, it would need to be part of Java. If this is an example of a package manager that works well, thanks, and we should try to understand what they do differently than the ones that are not working well. On a final note, I'm a little incredulous that this is considered to be such an intractable problem. I've designed, developed, worked on, used, and read about many many systems that are vastly more complicated than this. People write Java programs manage much more complex relationships than 'name.version->file' every single day.
  41. Hi James,

    I think I've found exactly what you're looking for:

    http://rubygems.org/

    Paul.


    That's great for Ruby but it doesn't help with Java.
    Yeah, I know - but I can't see why someone couldn't come up with a "javagems". JRake is out there already! Paul.
  42. Hi James,

    I think I've found exactly what you're looking for:

    http://rubygems.org/

    Paul.


    That's great for Ruby but it doesn't help with Java.


    Yeah, I know - but I can't see why someone couldn't come up with a "javagems". JRake is out there already!

    Paul.
    I guarantee it can be done. It's just a matter of getting buy-in at the top level. The kind of person that will go out an get an external application for managing the packages isn't the target I am thinking of. The person who 'really' needs this is the user that doesn't know a jar from a jpg. This is why such a system would need to be available by default. It would, however, definitely help developers and other power users too. I don't even think it would have to be too fancy either. I would say that recursive dependency evaluation should not be supported. It should be on the developer to specify all required packages, even those that are not directly used by his or her code. I'm sure tools would be developed to determine all the dependencies and create the correct configuration on the developer side.
  43. Yeah, I know - but I can't see why someone couldn't come up with a "javagems". JRake is out there already!

    Paul.
    Rubygems suffers from precisely the problems that I am trying to avoid in Java: http://rubyforge.org/pipermail/nitro-general/2006-April/003765.html
    "rubygems version hell"
    http://rubygems.org/read/chapter/19
    "After I updated RubyGems, I tried to install a gem and got parse errors:"
    http://forums.asmallorange.com/lofiversion/index.php/t8057.html
    "When I ran 'gem install rails --include-dependencies' I got: Bulk updating Gem source index for: http://gems.rubyforge.org /usr/local/lib/ruby/1.8/yaml.rb:133: [BUG] Segmentation fault ruby 1.8.5 (2006-08-25) [x86_64-linux]"
    http://www.oreillynet.com/cs/user/view/cs_msg/58299
    "A new version of Rails was released today, and it appears that it has a problem installing on Windows. I was able to reproduce it, and I also found a workaround. The workaround is to explicitly install the old version of Rails. You'd first have to uninstall each of Rails components that got installed before it blew up, but I think it would be easier just to start over and uninstall Ruby (either from the start menu entry or from add-remove programs)."
    This clearly illustrates what I am concerned about. I don't think it is reasonable to expect end users to have to deal with these sorts of problems.
  44. This clearly illustrates what I am concerned about. I don't think it is reasonable to expect end users to have to deal with these sorts of problems.
    I don't either. Why do you insist on using this invalid argument that because these problems exist in other systems, they are unavoidable? You posted an example of a bug (the error message says 'BUG' in it.) Give me a break. Bugs are are mistakes, they are not a fundamental part of a versioning system. There are many makes of automobile that have poor maintenance ratings because of flaws in their design. But my Honda has never broken down at over 120K miles. How can that be?
  45. I just got an error trying to install 1.6. Clearly, Sun should never have tried to provide installs on their website.
  46. I just got an error trying to install 1.6. Clearly, Sun should never have tried to provide installs on their website.
    The issue, of course, is that you are having this problem with a single package, not a mess of interdependent ones.
  47. I just got an error trying to install 1.6. Clearly, Sun should never have tried to provide installs on their website.


    The issue, of course, is that you are having this problem with a single package, not a mess of interdependent ones.
    And how does that help me?
  48. And how does that help me?
    Because the issues can be dealt with at one time rather than piecemeal. I would rather have issues with one download, sorted out on one occasion, than with a dozen downloads.
  49. And how does that help me?


    Because the issues can be dealt with at one time rather than piecemeal.

    I would rather have issues with one download, sorted out on one occasion, than with a dozen downloads.
    OK. Your preference trumps logic. Whatever.
  50. And how does that help me?


    Because the issues can be dealt with at one time rather than piecemeal.

    I would rather have issues with one download, sorted out on one occasion, than with a dozen downloads.


    OK. Your preference trumps logic. Whatever.
    Having a single install with associated issues to deal with as against possibly dozens of separate ones would seem to me to be the more logical approach. However, increasing the number and types of support issues may be logical in terms of keeping help desks busy :), so I guess it depends on your definition.
  51. And how does that help me?


    Because the issues can be dealt with at one time rather than piecemeal.

    I would rather have issues with one download, sorted out on one occasion, than with a dozen downloads.


    OK. Your preference trumps logic. Whatever.


    Having a single install with associated issues to deal with as against possibly dozens of separate ones would seem to me to be the more logical approach. However, increasing the number and types of support issues may be logical in terms of keeping help desks busy :), so I guess it depends on your definition.
    Why do you think bundling things into a single install reduces issues? The reason my first install failed was because a file was corrupted in transit. This is something that becomes much more likely as the size of the download increases.
  52. And how does that help me?


    Because the issues can be dealt with at one time rather than piecemeal.

    I would rather have issues with one download, sorted out on one occasion, than with a dozen downloads.


    OK. Your preference trumps logic. Whatever.


    Having a single install with associated issues to deal with as against possibly dozens of separate ones would seem to me to be the more logical approach. However, increasing the number and types of support issues may be logical in terms of keeping help desks busy :), so I guess it depends on your definition.


    Why do you think bundling things into a single install reduces issues? The reason my first install failed was because a file was corrupted in transit. This is something that becomes much more likely as the size of the download increases.
    Because you are still only dealing with a corruption of a single file. With dozens of separate files, each will have to be downloaded and validated separately. And the poor end user will have to cope with this.
  53. Because you are still only dealing with a corruption of a single file. With dozens of separate files, each will have to be downloaded and validated separately. And the poor end user will have to cope with this.
    A good design would use a digest (like MD5) that would not only verify that the download was good but also that the library is actually what it claims to be. Not to mention that a small downloads are rarely corrupted in transit, in my experience and if they were, the manager could easily retry, given that it won't take long. One small corrupted package means I have to download one small package again. One bad file in a 50MB download means I have to download 50MB again. Not to mention that when you have spotty connection to the network (like where I work) downloading 50 MB can be an extremely frustrating experience.
  54. One bad file in a 50MB download means I have to download 50MB again. Not to mention that when you have spotty connection to the network (like where I work) downloading 50 MB can be an extremely frustrating experience.
    I can understand that, having had the same experience. But that will be for the JDK. What we are talking about is the experience of the end user, who will be downloading the JRE, which is a fraction of that size.
  55. Steve and James[ Go to top ]

    Let me summarize the arguments. James: Getting users to do anything is hard, much less install a giant JRE, or worse, multiple versions of a giant JRE. The problem of building a package management system is tractable and therefore should to solved. Besides, dependencies extend beyond the JRE, and this solution could be applied to them as well. Steve: Current package management systems are failures for lay users. Making users deal with them will create nightmares. Don't even get me started on interactions with core OS native libraries. It's better to get an admin to install the whole kit-and-kaboodle at once than make users deal with dependency problems.
    I don't see a disagreement. James seems to be saying that a system could and should be built to manage Java dependencies. It can build off of experiences gathered with other package managers. Steve is saying that nothing currently in existence solves the problem sufficiently. So, James can write a package manager for the new open source Java 7 and in 5-10 years when it is proven in the field Steve will thank him for creating such a useful technology. Until then Steve will prefer the devil he knows.
  56. Re: Steve and James[ Go to top ]

    Steve is saying that nothing currently in existence solves the problem sufficiently.

    So, James can write a package manager for the new open source Java 7 and in 5-10 years when it is proven in the field Steve will thank him for creating such a useful technology. Until then Steve will prefer the devil he knows.
    Well, perhaps. The thing is, I just don't see it as being a useful technology, at least not yet. I think it will require a major effort to solve what currently seems to me to be a non-problem. Because I realise I can be single-minded and stubborn about things, I put this question of JRE size to some friends or colleagues who have between them decades of experience of software installation and user support. Not one thinks that the size of the JRE is an issue at all. So, as long as the JRE size doesn't grow too much, I would be impressed that someone had done it, but I don't believe I would thank that person, as I could see no use for it, at least not personally.
  57. Re: Steve and James[ Go to top ]

    Steve is saying that nothing currently in existence solves the problem sufficiently.

    So, James can write a package manager for the new open source Java 7 and in 5-10 years when it is proven in the field Steve will thank him for creating such a useful technology. Until then Steve will prefer the devil he knows.


    Well, perhaps. The thing is, I just don't see it as being a useful technology, at least not yet. I think it will require a major effort to solve what currently seems to me to be a non-problem.

    Because I realise I can be single-minded and stubborn about things, I put this question of JRE size to some friends or colleagues who have between them decades of experience of software installation and user support. Not one thinks that the size of the JRE is an issue at all.

    So, as long as the JRE size doesn't grow too much, I would be impressed that someone had done it, but I don't believe I would thank that person, as I could see no use for it, at least not personally.
    Hi Steve, I hesitate to get involved, because IMO the whole discussion has become a bit silly. But I will offer my 2 cents, simply because I've experienced James frustration myself. The are a whole range of reasons why someone may want a package manager for Java. Certainly if there was one there would be less reason to try and bundle everything in the JRE. James is not the only person to experience this itch, as demonstrated by the CJAR post by Konstantin. Personally, I feel that it is only a matter of time before the JVM (over Java) gets a package/library manager. The JVM as a runtime platform needs to manage libraries just like an OS. Windows and Mac OS X do it, with live updates, application installers etc, so why not the JVM? So the issue for me is why do you see this in such black and white terms? Perhaps splitting the JRE is not a good idea, but what about all those other jars that need to be downloaded, resulting in perhaps multiple copies lying around willy-nilly in the file system? I can tell that you think your mode of thought is logical, but I find it the opposite, I find it irrational. Like a kid that was once bit by a dog, and as developed a phobia against all four legged animals ever since. If everyone adapted such a narrow view of life, then many of the inovations that exist today just wouldn't be here. Imagine if the Right brothers decided that flying was too risky and ocean liners do a good job anyway? We would have no airplanes, and no cheap foriegn holidays (infact perhaps thats a good thing - hey maybe you're right after all, ocean liners are good enough, and could save the planet from global warming :^)) Paul.
  58. Re: Steve and James[ Go to top ]

    So the issue for me is why do you see this in such black and white terms? Perhaps splitting the JRE is not a good idea
    But that is my point - splitting the JRE is not a good idea. I some sort of general package management is not too bad an idea - I just have worries about end users managing this, but providing things were kept to pure Java libraries I would have less concern.
    Windows and Mac OS X do it, with live updates, application installers etc, so why not the JVM?
    Because those have issues too - just remember all the problems caused by XP Service pack 1 for example.
    Like a kid that was once bit by a dog, and as developed a phobia against all four legged animals ever since.
    I think it is best I ignore the 'irrational' comment, as I know you don't (I hope) mean to post flamebait, but regarding this statement the contrasting point of view seems less appropriate to me: don't learn from experience.
  59. Re: Steve and James[ Go to top ]

    I think it is best I ignore the 'irrational' comment, as I know you don't (I hope) mean to post flamebait, but regarding this statement the contrasting point of view seems less appropriate to me: don't learn from experience.
    Hi Steve, I guess you know me well. Flamebait is not my intention. What I am referring to is the idea of things being 'black' or 'white, and 'right' or 'wrong'. For example, seeing the choice as either 'dogs will always bite you' or as 'dogs will never bite you'. How about neither? James as a fledgling idea, that is worth exploring IMO. I'm not disagreeing that package managers generally have a bad rep, but then again so does Software. It doesn't stop us trying to improve - and like I said, if desktop Java does really take off (e.g. Java Webstart as mentioned by Erik), then this 'missing' functionality in the JVM would become worthy of considerable attention. Microsoft have launched WPF as an internet-aware client platform, and if the Java world chooses to respond, then client side package management may become an important missing piece. Paul.
  60. Re: Steve and James[ Go to top ]

    What I am referring to is the idea of things being 'black' or 'white, and 'right' or 'wrong'.
    I think you are reading 'black/white and right/wrong' where that is not intended. All I am expressing here is concerns, trying to be a 'Devil's advocate' as it were. I feel that having discussions like this is a good way to challenge ideas (especially my own). If I was certain, I would not bother - there would be no point.
  61. Java Application Manager found![ Go to top ]

    Hi All, My last post got me thinking. Why is it that the JVM hasn't got a package/library/application manager after all these years? For example Squeak has got one, just press update and your squeak image is updated to the latest build. As for third party packages, you can use Monticello to download and install along with all the dependencies. So why not the venerable JVM? Then it dawned on me. Java has had little success as a desktop client application platform. Most Java apps run on the server, with end-users accessing them over the web with HTTP. So with few Java desktop apps, there is little need to manage Java jars on the client. As for the server, well they are usually dedicated to a single application, and even when they're not us techie types are capable of dealing with all the package dependencies and complexities ourselves. So this got me thinking. Where is Java successful as a client platform? Then it came to me - on mobile devices. So I looked on my PocketPC Mobile phone and sure enougth, there it was, a Java application (midlet) manager. Allowing me to download and manage applications. In addition the J2ME runtime has optional packages than can be downloaded and installed independently, so for example RMI for J2ME is an optional package: http://developers.sun.com/techtopics/mobility/midp/articles/optional/ http://java.sun.com/javame/reference/docs/sjwc-1.1.3-web/pdf-html/port/ams.html So there we have it, all this talk and the answer was sitting under our noses all the time. If you want easy end-user client application management with Java then stick to mobile devices and J2ME :^). Paul.
  62. So why not the venerable JVM? Then it dawned on me. Java has had little success as a desktop client application platform. Most Java apps run on the server, with end-users accessing them over the web with HTTP.
    I'd add that most Java desktop applications are used by fair sized corporations, which are likely to repackage everything. Incidently, they seem to prefer fewer packages to more packages, and the "official" Java 5 install available on our network is the full JDK + Netbeans.
    So this got me thinking. Where is Java successful as a client platform? Then it came to me - on mobile devices. So I looked on my PocketPC Mobile phone and sure enougth, there it was, a Java application (midlet) manager. Allowing me to download and manage applications. In addition the J2ME runtime has optional packages than can be downloaded and installed independently, so for example RMI for J2ME is an optional package:
    That sounds like Java Web Start (I'm not a jws expert). JWS will go as far as to download an entire new (or old) JVM for you. But I'm going to venture a guess as to why package managers fail, and save James the time that he doesn't have of implementing something that Steve doesn't want. It's the packagers. Someone has the create a package that correctly defines the application's dependencies. So the application was written against 1.5_06 but the user has 1.5_09 installed - is that a problem? Well, probably not. But a brilliant packager could specify 1.5_06 as the required JRE build and boom you just got a huge download. Of course maybe the dependency is real because the application was tested against later versions and doesn't work. How does the package manager know?
  63. Re: Java Application Manager found![ Go to top ]

    But I'm going to venture a guess as to why package managers fail, and save James the time that he doesn't have of implementing something that Steve doesn't want.

    It's the packagers. Someone has the create a package that correctly defines the application's dependencies. So the application was written against 1.5_06 but the user has 1.5_09 installed - is that a problem? Well, probably not. But a brilliant packager could specify 1.5_06 as the required JRE build and boom you just got a huge download. Of course maybe the dependency is real because the application was tested against later versions and doesn't work. How does the package manager know?
    I was thinking about this and there are a few ways to address this and I'm not sure what would be the best way (including doing nothing). You could, list multiple versions, pattern matching (say 1.5 means any 1.5 verison), a simple syntax (1.5> means 1.5 and greater.) But I think in the end, it would be on the developer to make their package specify the correct versions in the deployment. If a new version of the JDK comes out, they should determine if it's usable for their app and if so deliver a small patch to update their dependencies. Another thing to realize that is if the JRE didn't have so much in it, the JRE wouldn't be a 'huge' download. The lib directory is close to 3/4s of the JRE. Also if you do a full search on your current machine, I think you'd be surprised by the number of JREs you already have. I always am when I do it. I just did it and found 31 instances of java.exe. A lot of those are related to WebSphere but there were a few that I had no idea about. A lot of applications are delivered with JREs because the reality is that hoping that the user's got a compatible JRE is very sketchy.
  64. Hi Guys, While you have been arguing the toss, some oen as already gone out ther and built it already. The is even a news item about it on TSS: http://www.theserverside.com/news/thread.tss?thread_id=43554 Raven apparently wraps Java jars into a ruby gem. I've used Rubygems and it works a treat for me. I've had issues with Linux package managers too, but comparing them to gems is like comparing night and day. Talking about night and day, I just can't see how this is a black and white issue. If done right then a package manager is a good idea. If done badly the of course its a pain. Installing apps on Mac OS X is a dream, yet it is still Unix. How do Apple manage to do it when the Linux distros can't? Steve, I think your pendantic tendencies are showing again... ease up a bit! Paul.
  65. While you have been arguing the toss, some oen as already gone out ther and built it already. The is even a news item about it on TSS:
    Sorry, no. This is an alternative for something already widely used in Java, called Maven. This is a system for managing project builds. Nothing new here.
    I've used Rubygems and it works a treat for me.
    Well that is OK then. Problem solved, as long as it works fine for you :)
    Installing apps on Mac OS X is a dream, yet it is still Unix. How do Apple manage to do it when the Linux distros can't?
    Because Apple controls everything - hardware and software. Linux has to install onto a wide range of hardware, and with a wide range of configurations. However, Mac OS X has its issues - software can be very sensitive to the version of Mac OS X.
    Steve, I think your pendantic tendencies are showing again... ease up a bit!
    And let people here down? I am surely by now expected to be pendantic....
  66. I've used Rubygems and it works a treat for me. I've had issues with Linux package managers too, but comparing them to gems is like comparing night and day.
    Yup...it's been a while since I've had a problem with a Linux package manager. When I installed RoR, I had to back-out the install multiple times because it crashed part way through and left the installation in an inconsistent state. Ultimately I had to figure out where the process was dying due to being unable to properly resolve dependencies and install them in the correct order myself. Fortunately I was able to find plenty of postings on the issue. So gems worked awful for me and worked wonderfully for you. In other words its reliability is unacceptable for lay users.
  67. Why do you insist on using this invalid argument that because these problems exist in other systems, they are unavoidable? You posted an example of a bug (the error message says 'BUG' in it.) Give me a break. Bugs are are mistakes, they are not a fundamental part of a versioning system.
    I posted those examples both to show general issues about package management and to show the specific problems that have turned up with rubygems, as it was being suggested as a specific example of how things could be done right, and Java packaging could be solved if only a port of to Java were done. In the latter context, showing bugs is relevant.
    There are many makes of automobile that have poor maintenance ratings because of flaws in their design. But my Honda has never broken down at over 120K miles. How can that be?
    Perhaps because the Honda has a simpler and more robust design - just like a single JRE install.
  68. Perhaps because the Honda has a simpler and more robust design - just like a single JRE install.
    That's false. The design of a my car in mot simpler. It's many ways it's more complex than the average car. For example it has a VTEC engine (Variable valve Timing and Electronic lift Control.)
  69. Why do you insist on using this invalid argument that because these problems exist in other systems, they are unavoidable? You posted an example of a bug (the error message says 'BUG' in it.) Give me a break. Bugs are are mistakes, they are not a fundamental part of a versioning system.


    I posted those examples both to show general issues about package management and to show the specific problems that have turned up with rubygems, as it was being suggested as a specific example of how things could be done right, and Java packaging could be solved if only a port of to Java were done. In the latter context, showing bugs is relevant.
    You still haven't answered any of the direct questions I have asked about why you think this would happen with Java.
  70. BTW the size of the 1.6 JRE is currently 87.1 MB for Windows.
  71. BTW the size of the 1.6 JRE is currently 87.1 MB for Windows.
    That is the size of after installation. I assumed we were talking about download size. Given a 40GB disk (the smallest you can find these days on a new PC 87.1 MB is 0.22%. There is space for hundreds of JRE installs, if you are so inclined.
  72. You still haven't answered any of the direct questions I have asked about why you think this would happen with Java.
    OK, a direct answer. There will be problems with a Java package management system because there are problems with all package management systems and because Java developers don't have superhuman abilities to avoid bugs. And even if they did, it would introduce more complexity for the end user, in that they would have to approve of a range of package downloads. A single wrong mouse click (on 'cancel' rather than 'ok'), or a broken network connection, and packages don't get installed, the application breaks and you end up with a support issue. And yet again (I have lost count how many times I have mentioned this), there are parts of Java that have system dependencies that you don't want end users to have to deal with.
  73. You still haven't answered any of the direct questions I have asked about why you think this would happen with Java.


    OK, a direct answer. There will be problems with a Java package management system because there are problems with all package management systems and because Java developers don't have superhuman abilities to avoid bugs.
    So you will use the JVM, and libraries written by these developers but they can't be trusted to write what amounts to a file repository?
    And even if they did, it would introduce more complexity for the end user, in that they would have to approve of a range of package downloads.
    Once for each package. I fail to see why this is so much of a burden. 'your application requires . Do you want Java to install the package' User clicks no. 'You must install to run this application. The application will now close.' The user would have to run the app again and select 'yes'. What's the big problem? The other way you could deal with this is to deliver the needed jars with your app, if you were this concerned about the user's ability to select 'yes'.
    A single wrong mouse click (on 'cancel' rather than 'ok'), or a broken network connection, and packages don't get installed, the application breaks and you end up with a support issue.
    But we already have support issues. Users upgrade the JRE and things stop working. They install a new piece of Java software than puts something in the classpath variable or points 'java' to an incompatible JRE. I've had to deal with these issues. What is your solution for these problems? Do nothing? That's what I don't get. You act as if the current situation is great. It's chaos. There is no support for the user right now. The users are on their own. unless someone helps them. I listen to users and admins groan about Java because their experiences with it are configuration nightmares. The only people that can configure Java and Java apps properly are Java programmers. Nothing would force anyone to use the package manager. The only reason they would is because it would be helpful to them. I don't see why there couldn't be a giant spitball download for those that want it.
    And yet again (I have lost count how many times I have mentioned this), there are parts of Java that have system dependencies that you don't want end users to have to deal with.
    And I asked how the current situation deals with this. I'm still waiting.
  74. So you will use the JVM, and libraries written by these developers but they can't be trusted to write what amounts to a file repository?
    It isn't just a file repository; it is an entire package management system for novice users.
    Once for each package. I fail to see why this is so much of a burden. 'your application requires . Do you want Java to install the package'

    User clicks no. 'You must install to run this application. The application will now close.'

    The user would have to run the app again and select 'yes'. What's the big problem?

    The other way you could deal with this is to deliver the needed jars with your app, if you were this concerned about the user's ability to select 'yes'.
    You obviously haven't dealt with the kind of end users I have!
    But we already have support issues. Users upgrade the JRE and things stop working. They install a new piece of Java software than puts something in the classpath variable or points 'java' to an incompatible JRE. I've had to deal with these issues. What is your solution for these problems? Do nothing? That's what I don't get. You act as if the current situation is great.
    No, I am not. I just don't want things to get worse, with not just incompatible JREs, but potentially incompatible modules of JREs, with poorly-written applications breaking when you update a module, not just the entire JRE. Unless, of course, you install an entire JRE + appropriate modules for every application - is that what you are suggesting?
    There is no support for the user right now. The users are on their own. unless someone helps them. I listen to users and admins groan about Java because their experiences with it are configuration nightmares. The only people that can configure Java and Java apps properly are Java programmers.
    Indeed. And you want to allow end users to do that.
    Nothing would force anyone to use the package manager. The only reason they would is because it would be helpful to them. I don't see why there couldn't be a giant spitball download for those that want it.

    Sorry, but all I see is you introducing more configuration.
    And yet again (I have lost count how many times I have mentioned this), there are parts of Java that have system dependencies that you don't want end users to have to deal with.
    And I asked how the current situation deals with this. I'm still waiting.
    And I have told you. The end users don't have to deal with this at the moment - issues of system library dependencies can be dealt with at a single point - the installation of the full JRE. With your setup, the user downloads an application, and it says 'loading dependency AWT.... sorry, this requires a later version of libwhatever.so.99. Please install this and try again'. Then the end user is either mystified, or attempts to upgrade libwhatever using their Linux package manager. The upgrade requires dozens of additional packages. The user (with their slow modem) waits... then the phone goes down, leaving things half-installed, or some temporary files and locks left by the package manager need to be cleared up. And so on.
  75. But we already have support issues. Users upgrade the JRE and things stop working. They install a new piece of Java software than puts something in the classpath variable or points 'java' to an incompatible JRE. I've had to deal with these issues. What is your solution for these problems? Do nothing? That's what I don't get. You act as if the current situation is great.


    No, I am not. I just don't want things to get worse, with not just incompatible JREs, but potentially incompatible modules of JREs, with poorly-written applications breaking when you update a module, not just the entire JRE.
    You just aren't following me. There would be no way to 'update' a module. You could get another version but that would have no impact on already installed applications. An application would never get a different version unless it requests a different version. I've written this several times.
    The end users don't have to deal with this at the moment - issues of system library dependencies can be dealt with at a single point - the installation of the full JRE.
    If it can be handled by the JRE install, why couldn't a package manager (configured by the JRE install) handle it?
    With your setup, the user downloads an application, and it says 'loading dependency AWT.... sorry, this requires a later version of libwhatever.so.99. Please install this and try again'.
    And this doesn't happen with the full JRE? Either you have the problem initially or you have it later. I don't see why it's better up front. Especially if not all users need that module anyway.
    Then the end user is either mystified, or attempts to upgrade libwhatever using their Linux package manager. The upgrade requires dozens of additional packages. The user (with their slow modem) waits... then the phone goes down, leaving things half-installed, or some temporary files and locks left by the package manager need to be cleared up. And so on.
    I'm not talking about that package manager. That it's flawed has nothing to do with what I am proposing. Java having a package manager of it's own doesn't make the Debian package manager better or worse. It's a separate subject.
  76. You just aren't following me.
    Perhaps not. Sometimes patience is required with me :)
    There would be no way to 'update' a module. You could get another version but that would have no impact on already installed applications. An application would never get a different version unless it requests a different version. I've written this several times.
    That may work with general jars, but it isn't going to work with major parts of the JRE - there is too much inter-dependency. Imagine trying to run two different versions of Swing+AWT on the same JVM. Also, think of the support issues - you aren't just dealing with JRE 1.5.0_10, but JRE "core" 1.5.0_10 with modules at 1.5.0_08 or 1.5.0_06...
    If it can be handled by the JRE install, why couldn't a package manager (configured by the JRE install) handle it?
    Because these things aren't handled automatically by the JRE install. They are handled separately by a system admin (or someone capable) at the time of the JRE install. I would not want something like a JRE install automatically updating major system libraries!
    With your setup, the user downloads an application, and it says 'loading dependency AWT.... sorry, this requires a later version of libwhatever.so.99. Please install this and try again'.


    And this doesn't happen with the full JRE? Either you have the problem initially or you have it later. I don't see why it's better up front.
    It is better up front because it can be dealt with as a one-off issue by a sysadmin or someone capable. If you leave it till later you are expecting someone less experienced to deal with this.
    Then the end user is either mystified, or attempts to upgrade libwhatever using their Linux package manager. The upgrade requires dozens of additional packages. The user (with their slow modem) waits... then the phone goes down, leaving things half-installed, or some temporary files and locks left by the package manager need to be cleared up. And so on.


    I'm not talking about that package manager. That it's flawed has nothing to do with what I am proposing. Java having a package manager of it's own doesn't make the Debian package manager better or worse. It's a separate subject.
    No, it isn't. Because if you are breaking up the JRE to the point where you are requiring that the end user downloads modules with native binary components, then those binary components may have operating system dependencies (this is certainly the case with AWT). This means that the installation of those native binary JRE components of necessity requires additional operating system management. Either you attempt to link that to the Java package manager (which would be dangerous - you would have Java attempting to download and install rpms or debs or whatever) or you require the end user to use the native Linux package manager, or wait for someone more experienced to do this. (Also, I mentioned the Debian package manager because it is one of the better known and tested package managers out there, and it has issues)
  77. You just aren't following me.


    Perhaps not. Sometimes patience is required with me :)

    There would be no way to 'update' a module. You could get another version but that would have no impact on already installed applications. An application would never get a different version unless it requests a different version. I've written this several times.


    That may work with general jars, but it isn't going to work with major parts of the JRE - there is too much inter-dependency. Imagine trying to run two different versions of Swing+AWT on the same JVM.
    Seriously, I don't get the issue. I'm not just arguing to win here. Can you spell it out for me? What kind of problems are you thinking of? I suppose I am imagining that if a library needs a specific binary, it would provide it as part of its download. Maybe that won't work in certain cases. Maybe I'm being naive. I just don't see how it would be a problem if it's not one now. I've got multiple JRE versions on my Linux machine and I haven't had any issues.
    Also, think of the support issues - you aren't just dealing with JRE 1.5.0_10, but JRE "core" 1.5.0_10 with modules at 1.5.0_08 or 1.5.0_06...
    This is a legitimate concern. But I still think you aren't fully getting what I am saying. Whatever the application developer has tested the code on and specified it will use would be the version it runs on. You would support an application, not a specific set of modules. I've had to work with applications where one used version A of a certain library and another used version B. The support problems came not from using the two jars but keeping the applications from seeing the wrong jar. This would eliminate that issue. You wouldn't have to wonder if they were using the right version of the libraries, the JVM would ensure the application was using what the developers specified. So while you might have some complications around the package management, it could also alleviate a lot of issues. Another thing it could resolve would be that a lot of bugs in the JDK could be fixed. Instead of just saying that fixing the problem might break existing code, the problems could be fixed and released as a new version. Developers could then test against the new version and we could move on instead of just living with flawed or suboptimal behavior.
    If it can be handled by the JRE install, why couldn't a package manager (configured by the JRE install) handle it?


    Because these things aren't handled automatically by the JRE install. They are handled separately by a system admin (or someone capable) at the time of the JRE install.

    I would not want something like a JRE install automatically updating major system libraries!
    I wouldn't want it to either. If i were to design it, anything outside of Java would not be supported.
    With your setup, the user downloads an application, and it says 'loading dependency AWT.... sorry, this requires a later version of libwhatever.so.99. Please install this and try again'.


    And this doesn't happen with the full JRE? Either you have the problem initially or you have it later. I don't see why it's better up front.
    It is better up front because it can be dealt with as a one-off issue by a sysadmin or someone capable. If you leave it till later you are expecting someone less experienced to deal with this.
    Where does the sysadmin go? I would imagine that if the sysadmin installed a Java app that required something like this, the issue would have to be dealt with at that time. If the user had a locked down machine, the package manager should also be locked down.
    Then the end user is either mystified, or attempts to upgrade libwhatever using their Linux package manager. The upgrade requires dozens of additional packages. The user (with their slow modem) waits... then the phone goes down, leaving things half-installed, or some temporary files and locks left by the package manager need to be cleared up. And so on.


    I'm not talking about that package manager. That it's flawed has nothing to do with what I am proposing. Java having a package manager of it's own doesn't make the Debian package manager better or worse. It's a separate subject.


    No, it isn't. Because if you are breaking up the JRE to the point where you are requiring that the end user downloads modules with native binary components, then those binary components may have operating system dependencies (this is certainly the case with AWT). This means that the installation of those native binary JRE components of necessity requires additional operating system management. Either you attempt to link that to the Java package manager (which would be dangerous - you would have Java attempting to download and install rpms or debs or whatever) or you require the end user to use the native Linux package manager, or wait for someone more experienced to do this.

    (Also, I mentioned the Debian package manager because it is one of the better known and tested package managers out there, and it has issues)
    Again, I don't see how this is different from the current situation. If the user needs these things they need them now. Having a package manager isn't going to create these problems. Probably, AWT and Swing should be bundled with the JRE, they are likely to be needed by most people, especially end users. My point isn't that we necessarily have to go bare-bones. It's just that the additions to the JRE are unrelenting and some of the additions are so questionable, not only in terms of universality but in terms of quality. I think a lot of superior Java packages have been sidelined by inferior packages written by more connected people. It's crazy that we have all the JMX libraries in the JDK but no decent Date class. In addition to this problem, we already have a package management problem in Java. The current 'solution' is to bundle things into the JRE. But at some point, it's just too much. You can't bundle everything useful into the JRE. There are just too many libraries out there. I think it could be done. I don't disagree that current solutions are not reliable enough. Most software isn't, in my estimation. And Erik, while I'd love to write something like this, I'm busy working on a library to convert flat data to Java based on COBOL data declarations. I also think a secure central server cluster with full 3rd party certification would be required and I just don't have the resources to pull this off right now.
  78. ... I also think a secure central server cluster with full 3rd party certification would be required and I just don't have the resources to pull this off right now.
    Yeah, that is my dream too: http://www.searchj.org/info/about/cjar_everyday_use.png I even created a kind of package discovery interface that I would like to evolve into full repository management tool that would allow to upload new packages and dependency definitions http://www.kgionline.com/cjar/app?page=SubmitArtifactForm&service=external
  79. I may reply to more of your post later, but...
    Probably, AWT and Swing should be bundled with the JRE, they are likely to be needed by most people, especially end users. My point isn't that we necessarily have to go bare-bones.
    This is illustrates one of the issues I have been trying to explain from the start: how do you decide where to split JRE? A while back you said:
    We could remove CORBA, Swing, AWT, I could go on for quite a while. Pretty much anything that isn't a core class or utility could be a candidate.
    Now you say that probably AWT and Swing should be bundled. I am not trying to trip you up with inconsistencies - simply to point out that things are complicated. What can seem like a simple idea - splitting up the JRE - can turn out not to be. I have perhaps persuaded you about this because of certain native library problems with Swing + AWT. If we went on discussing, I believe I could persuade you to keep other parts of the JRE because of strong dependencies. My feeling is that what would be left over to strip out would be so small as to not be worth dealing with.
  80. I may reply to more of your post later, but...

    Probably, AWT and Swing should be bundled with the JRE, they are likely to be needed by most people, especially end users. My point isn't that we necessarily have to go bare-bones.


    This is illustrates one of the issues I have been trying to explain from the start: how do you decide where to split JRE?

    A while back you said:

    We could remove CORBA, Swing, AWT, I could go on for quite a while. Pretty much anything that isn't a core class or utility could be a candidate.


    Now you say that probably AWT and Swing should be bundled.

    I am not trying to trip you up with inconsistencies - simply to point out that things are complicated.
    I haven't really sat down and figured out what packages should stay and which should go. It's not really the point. I was just thinking that if AWT and Swing weren't installed, it would probably be installed right away by most end users. Maybe not. I don't know. Which packages should be bundled and which should not isn't really what I am getting at.
    What can seem like a simple idea - splitting up the JRE - can turn out not to be.

    I have perhaps persuaded you about this because of certain native library problems with Swing + AWT. If we went on discussing, I believe I could persuade you to keep other parts of the JRE because of strong dependencies. My feeling is that what would be left over to strip out would be so small as to not be worth dealing with.
    I'm, still not convinced that packaging AWT separately is going to create any great problem that doesn't already exist. My experiences with binaries required by jars in Unix was that the vendor supplied the binaries and we put them where we wanted and added that directory to the LD_LIBRARY_PATH. I don't see why a package manager couldn't do this without messing up other parts of the system. Maybe the gui stuff is different and needs to be set up for the whole system. It's really not my area of expertise. I am currently writing Java to run on OS400 which is green screen, so AWT and Swing aren't needed or usable for this purpose. They are most likely there, at least in some sort of shell fashion because they are part of the JDK. That strikes me as a little silly.
  81. hich packages should be bundled and which should not isn't really what I am getting at.
    It was part of what I was getting at - that there would be much debate about how do to this, with many incompatible ideas about how to proceed.
    I'm, still not convinced that packaging AWT separately is going to create any great problem that doesn't already exist. My experiences with binaries required by jars in Unix was that the vendor supplied the binaries and we put them where we wanted and added that directory to the LD_LIBRARY_PATH. I don't see why a package manager couldn't do this without messing up other parts of the system. Maybe the gui stuff is different and needs to be set up for the whole system. It's really not my area of expertise.
    I am afraid it is something I have had to deal with, and it does indeed involve libraries that need to be set up for the whole system. Many of the libraries can indeed be put into LD_LIBRARY_PATH, but they may have been compiled with system dependencies, such as libc versions. I realise I was discussing an 'edge case' here, and this kind of thing would not apply to much of the JRE, but what I was trying to illustrate was that what may seem simple can cause other unforeseen difficulties.
    They are most likely there, at least in some sort of shell fashion because they are part of the JDK. That strikes me as a little silly.
    I can see why you think that, but as you don't have to use them... who cares? Anyway, I can't think of much else to post about this - you have introduced some interesting ideas that will give me much to think about, and has let to useful discussions with colleagues. I am still far from convinced, but thanks for the discussion anyway.
  82. They are most likely there, at least in some sort of shell fashion because they are part of the JDK. That strikes me as a little silly.


    I can see why you think that, but as you don't have to use them... who cares?
    Well, it's probably not a concern but here's an example of something that I had a problem with in the past. I was working on a program to integrate with another teams application. In order to update their database they had to copy and paste a lot of code into a new app that I, unhappily, ended up maintaining. Somewhere in the reams of code they supplied, they had 'error handling' that threw up a dialog and blocked for a user to click OK. This code was running as a service on a remote server and whenever this error occurred (caused by buggy logic in their code) it would freeze up. This took a long time to diagnose. If the library wasn't packaged with the JDK, I would have known that this invalid dependency was there in the beginning and could have gone back to that team and demanded they to get rid of it. Once I figure out what was going on, it was too late.
  83. hich packages should be bundled and which should not isn't really what I am getting at.


    It was part of what I was getting at - that there would be much debate about how do to this, with many incompatible ideas about how to proceed.
    It seems like they are able to add things to the JDK without too much trouble. I don't see why deciding to break things off would be so hard. In any event, a 'full' JRE download would still need to be available. Even if nothing were removed, I think a package manager would still provide value.
  84. hich packages should be bundled and which should not isn't really what I am getting at.


    It was part of what I was getting at - that there would be much debate about how do to this, with many incompatible ideas about how to proceed.


    It seems like they are able to add things to the JDK without too much trouble. I don't see why deciding to break things off would be so hard.
    That is because when you add things, you introduce dependencies, which can be hard to undo. This is a common experience - just look at how the kernels of some operating systems have grown, and retrospectively splitting them up has become extremely difficult.
    In any event, a 'full' JRE download would still need to be available. Even if nothing were removed, I think a package manager would still provide value.
    Yes, I can see the advantage of that, for general use.
  85. That is because when you add things, you introduce dependencies, which can be hard to undo. This is a common experience - just look at how the kernels of some operating systems have grown, and retrospectively splitting them up has become extremely difficult.
    I agree completely and this is part of the reason why I am so concerned that things are being thrown into the JDK in such a cavalier fashion. Every hot technology around the time of the release becomes forever part of the JDK. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?
  86. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?
    No you're wrong it will never work! :^)
  87. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?

    No you're wrong it will never work! :^)
    I guess no one found my satire funny then :^).
  88. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?

    No you're wrong it will never work! :^)

    I guess no one found my satire funny then :^).
    I give it a 3.5. If it makes you feel any better, people in this forum rarely find my sarcasm funny.
  89. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?

    No you're wrong it will never work! :^)

    I guess no one found my satire funny then :^).
    A something is only satirical if it is close to what someone actually said. What you should have posted is: "You're wrong, because my decades of experience convince me that this is absolutely impossible and if you allow anyone but a sysdadmin to do this it will melt your hardware" See what I mean? :)
  90. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?

    No you're wrong it will never work! :^)

    I guess no one found my satire funny then :^).


    A something is only satirical if it is close to what someone actually said.

    What you should have posted is:

    "You're wrong, because my decades of experience convince me that this is absolutely impossible and if you allow anyone but a sysdadmin to do this it will melt your hardware"

    See what I mean? :)
    Steve, Yes, I see your point, much better. I would give yours an 8.5. Merry Christmas and a Happy New Year to you all, Paul.
  91. If they would just slow down or stop around where they are now, it would be a great thing. You are probably right that cleanup will not be feasible but a guy can dream, can't he?

    No you're wrong it will never work! :^)
    The little smiley at the end ruins it for me. I like my sarcasm biting and/or caustic. It's a conundrum, though as it's hard to get that mean sarcastic tone across in a forum post. Believe me, I've tried. No one thinks my jokes are funny so you are in good company. I'm not sure if they know that I am joking or not. I'm pretty dead-pan which can be confusing in person say nothing of a post. Are there dead-pan humor and sarcasm smileys?
  92. href="http://www.oreillynet.com/cs/user/view/cs_msg/58299" target="_blank">http://www.oreillynet.com/cs/user/view/cs_msg/58299

    "A new version of Rails was released today, and it appears that it has a problem installing on Windows. I was able to reproduce it, and I also found a workaround.

    The workaround is to explicitly install the old version of Rails. You'd first have to uninstall each of Rails components that got installed before it blew up, but I think it would be easier just to start over and uninstall Ruby (either from the start menu entry or from add-remove programs)."


    This clearly illustrates what I am concerned about. I don't think it is reasonable to expect end users to have to deal with these sorts of problems.
    This is exactly the kind of think I am not talking about. Shame on the Rails team for overlaying the new version of the application over top of the old. That's a rookie mistake. This is what I am getting at. These systems have problems because they have a design that doesn't meet the needs of the users. I have 2 versions of the Sun JRE installed on my machine, plus a couple Eclipse/IBM versions That I didn't add. None of these conflict with each other and each Java application is set up to use the appropriate version. This is the reality. You must support different concurrent versions of the same libraries. If the versioning system doesn't support that, then there is no hope of it succeeding. The problems you keep mentioning will be inevitable.
  93. On a final note, I'm a little incredulous that this is considered to be such an intractable problem. I've designed, developed, worked on, used, and read about many many systems that are vastly more complicated than this. People write Java programs manage much more complex relationships than 'name.version->file' every single day.
    Because things aren't that simple, as I keep describing. For example, I have repeatedly mentioned the issue of binary modules with OS library dependencies, and simply saying 'just download the version for Linux' won't work. These things aren't intractable, but developing something that could potentially manage different versions of different java and native packages for different versions of the JRE all on the same machine, and in a way that is failsafe and automatic enough for Joe Public to use isn't going to be easy. And as I said, if things go wrong because the package manager can't connect to the Apache library to download the particular commons library you need, the end user will blame you. And I believe it is a waste of time trying to do this for a non-problem. Perhaps when the JRE grows to 100MB, I'll change my mind!
  94. Because things aren't that simple, as I keep describing. For example, I have repeatedly mentioned the issue of binary modules with OS library dependencies, and simply saying 'just download the version for Linux' won't work.
    So how exactly is this solved in the current system?
    These things aren't intractable, but developing something that could potentially manage different versions of different java and native packages for different versions of the JRE all on the same machine, and in a way that is failsafe and automatic enough for Joe Public to use isn't going to be easy.
    I didn't say it was going to be 'easy' but I don't think it's going all that difficult either. I think you vastly overestimate the complexity involved. What exactly is it that you think would make it so difficult? Why would it be hard to have a repository that organizes libraries by version and target OS and a local repository that organizes things only be version?
    And as I said, if things go wrong because the package manager can't connect to the Apache library to download the particular commons library you need, the end user will blame you.
    And if the user can't manually find the library, download it, put it in the correct place and possible update the classpath, who do they blame. Again you are still using the argument that something might go wrong, so let's not try. Google should shut down their operations because someone might not be able to get to their website. I can't even understand why they would build a business around the internet. Don't they know that it's unreliable?!
    And I believe it is a waste of time trying to do this for a non-problem. Perhaps when the JRE grows to 100MB, I'll change my mind!
    What is it now? 80, 85? I don't have 1.6 yet.
  95. So how exactly is this solved in the current system?
    I thought we had been over this. It is less of a problem and simpler to manage because it can be dealt with at one time when the JRE is installed. It is something a sysadmin installing the JRE can deal with, rather than something that has to be dealt with possibly whenever a user downloads any Java app.
    What exactly is it that you think would make it so difficult?
    Because I have seen and used so many attempts to do this.
    I didn't say it was going to be 'easy' but I don't think it's going all that difficult either. I think you vastly overestimate the complexity involved.
    I think it would be complex to make something totally failsafe and suitable for the general public, but perhaps you are right. My main disagreement with you is that I honestly can't see the point.
    Why would it be hard to have a repository that organizes libraries by version and target OS and a local repository that organizes things only be version?
    We have been over this. For one thing, 'target OS' is not a sensible criterion. Individual installations of Linux can vary widely in the packages and libraries that are installed, and parts of the JRE with binary libraries can rely on these packages being installed. With a single JRE install this can be dealt with once only, by someone with system admin access. It isn't reasonable for an end user's download of a small Java application for personal use to trigger a major update of system libraries. Java is supposed to avoid such concerns.
    And if the user can't manually find the library, download it, put it in the correct place and possible update the classpath, who do they blame.
    The user doesn't have to manually find the library - it is included as part of the application's distribution, managed by an installer. However, managing things for a single application installation is not the same as managing things for system-wide JRE setups.
    Again you are still using the argument that something might go wrong, so let's not try.
    No, I am using the argument that because something almost certainly will go wrong, let's not bother unless we really have to.
    Google should shut down their operations because someone might not be able to get to their website. I can't even understand why they would build a business around the internet. Don't they know that it's unreliable?!
    Hardly a fair comparison. End users don't have to run and install packages or go through a complex process to access google. It is only a single URL to get to Google. At the moment, it is only a single download to get the full JRE.

    And I believe it is a waste of time trying to do this for a non-problem. Perhaps when the JRE grows to 100MB, I'll change my mind!


    What is it now? 80, 85? I don't have 1.6 yet.
    As already discussed, 15MB installer for Windows.
  96. What is the big deal? I remembered there was a thread on Eclipse vs Netbean IDE. Some people like Netbeans IDE better because it include all plugins out of the box and Eclipse IDE doesn't. Too much? people complain. Too little? still complain. May be Sun should leave java.net package out and make it a separate download. :)
  97. It makes sense to have them in Java as a standard, but how good is the current implementation?
    Of course it does NOT make any sense to bundle everything into JRE! JRE should evolve into highly modular system which core is 1 -1.5 MB and the rest should be just downloadable modules. Of course there should be a 'standard' repository of modules and people should be able to add own repositories at will. JRE is sort of Operation System and should feel and behave as one. Take any modern GNU-Linux distribution, all it takes to get new library/app/whatever is (apt-get|emerge|etc) it should be the same kind of simplicity in Java
  98. It makes sense to have them in Java as a standard, but how good is the current implementation?

    Of course it does NOT make any sense to bundle everything into JRE!

    JRE should evolve into highly modular system which core is 1 -1.5 MB and the rest should be just downloadable modules.

    Of course there should be a 'standard' repository of modules and people should be able to add own repositories at will.
    JRE is sort of Operation System and should feel and behave as one. Take any modern GNU-Linux distribution, all it takes to get new library/app/whatever is
    (apt-get|emerge|etc)
    it should be the same kind of simplicity in Java
    This is anything but simplicity. I think it is unreasonable to expect end users to have to deal with this kind of thing. Even if they are capable of running the equivalent of package managers, why should they have to? There are enough issues involved with managing library versions during development - to expect end-users to have to manage not just different versions of the JRE, but different versions of sub-components for each JRE.... I really don't expect users who download or install my Java software to have to run the equivalent of 'apt-get'! I can't help but feel that complaints about the size of the JRE are vastly exaggerated. Considering the size of much commercial and shrink-wrapped software, a 12.6MB download or install (for Windows) is trivial.
  99. ...This is anything but simplicity.
    Yeah, I admit that I made my message to brief and did not elaborate enough. So here it is: IMO apt-get kind of approach is _enabler_for more automated and transparent dependency management, which I imagine as sort of improved Java Web Start. My point is that dependency management in GNU-Linux distros demonstrate that reliable and convenient dependencies management is possible and can be done. Therefore I would like to see explicit and robust support for modules and modules management in Java. At this time I see efforts to include everything in one package as futile and leading to a dead end, it is simple as that.
  100. ...This is anything but simplicity.


    Yeah, I admit that I made my message to brief and did not elaborate enough. So here it is:
    IMO apt-get kind of approach is _enabler_for more automated and transparent dependency management, which I imagine as sort of improved Java Web Start.
    My point is that dependency management in GNU-Linux distros demonstrate that reliable and convenient dependencies management is possible and can be done.
    Therefore I would like to see explicit and robust support for modules and modules management in Java.
    At this time I see efforts to include everything in one package as futile and leading to a dead end, it is simple as that.
    I see your point, but I just don't think it is practical. My experience over the years with dependency management in GNU-Linux distros is that it can go badly wrong and can require expert intervention to tidy things up afterwards. When other systems have attempted such modularisation in the past the results have often been messy and complex - just think back to DLL-hell: http://en.wikipedia.org/wiki/DLL_hell Dependency management is hard enough for sysadmins and developers, let alone users, no matter how good the automated tools. I really don't see that much of an issue about including thing s in one package providing the package is reasonably small, and I just don't think the JRE download is that big. If it were 50-100MB of download, sure, then size would be an issue. I think the benefits of knowing for sure what is in a JRE that is a single download hugely outweigh other issues.
  101. ...[ Go to top ]

    I think the benefits of knowing for sure what is in a JRE that is a single download hugely outweigh other issues.
    I agree, and I also think that it is important to have a single standard Java Web Services toolkit available, awkward as it may be.
  102. I think the benefits of knowing for sure what is in a JRE that is a single download hugely outweigh other issues.
    Scoping the JRE. Who is the one to use JRE? Clients, little apps running in my machine, APP servers, message queues... It is a very broad target I guess. Should JRE be the minimum any application needs to run?. Could WS be in that minimum? By concept, WS is not a human-to-machine paradigm, it is an application-to-application one. So, WS is not for everybody, but for a few. If such, should we add to JRE something that the majority "may" use? I think that is more a question of packing that a question of defining the scope of a runtime. William Martinez Pomares.
  103. When other systems have attempted such modularisation in the past the results have often been messy and complex - just think back to DLL-hell: http://en.wikipedia.org/wiki/DLL_hell
    I never want to return to that (was once a VB developer - ok I still gotta touch the stuff). I don't depend on the global classpath in Java. I set it at run time. And when I do .Net, I dont't use the GAC for anything (makes me wanna yack).
  104. ...This is anything but simplicity.


    Yeah, I admit that I made my message to brief and did not elaborate enough. So here it is:
    IMO apt-get kind of approach is _enabler_for more automated and transparent dependency management, which I imagine as sort of improved Java Web Start.
    My point is that dependency management in GNU-Linux distros demonstrate that reliable and convenient dependencies management is possible and can be done.
    Therefore I would like to see explicit and robust support for modules and modules management in Java.
    At this time I see efforts to include everything in one package as futile and leading to a dead end, it is simple as that.
    I theory I totally agree with you, and in general I think package management in linux work pretty good. On the other hand many of my friends hosed their distros because of package management problems. I have gotten a lot of free beer over the last few years thanks to linux package management problems.
  105. I theory I totally agree with you, and in general I think package management in linux work pretty good. On the other hand many of my friends hosed their distros because of package management problems. I have gotten a lot of free beer over the last few years thanks to linux package management problems.
    That is where Java has certain advantages and ways to cope with the dependencies management. The problem with OSes is that common stuff is just that - common and thus affects everybody, although kernel modules are managed in smarter way and therefore it is possible form multiple kernels to coexist and possible to screw one without affecting others. Java is OS within the OS and therefore "common" things are not that "common". So, if one application has bad dependencies declaration, like [1,*] open range then it will screw itself by downloading new buggy version 3.0, smarter ones will continue to use whatever they want/need to. There is exactly what war and ear in J2EE servers allows us to do, And that is what Java Web Start provides on clients, well sort of. There are few easily addressable shortcomings in JNLP protocol which make it less than perfect: - inability to point to a different repository for dependencies; - prohibition to have multiple signatures on jars; Other than that JWS is almost perfect. Ohh, and too bad that JWS does not support Applets as Applets :( that would be real cool if it did!
  106. That is where Java has certain advantages and ways to cope with the dependencies management.... There is exactly what war and ear in J2EE servers allows us to do,And that is what Java Web Start provides on clients, well sort of
    I am not so sure. We are talking about far more that different versions of, say, Apache commons libraries or JDBC drivers running on different applications in an app server - we are talking about functionality that can span most of the Java platform. Also, we aren't talking about dependencies that can be easily isolated. Modules that make up the kind of JRE you describe would indeed be common, as they would form the runtime environment of every app that used that JRE and the possibilities for conflicts and version problems are considerable. We are talking not about how Java manages dependencies, as we are talking mostly about dependencies in the implementation of the Java platform itself. For example, consider GUI implementation. Looks like a good candidate for separating out. However, you aren't just managing Jars, you are managing platform-dependent native libraries as well.
  107. On the other hand many of my friends hosed their distros because of package management problems. I have gotten a lot of free beer over the last few years thanks to linux package management problems.
    But seriously, it is pretty easy to hose a Linux installation if you don't know what you're doing, and you don't know until you've hosed your system a few times. They're great as long as you stay in their box.
  108. Why not?[ Go to top ]

    Look at what users get, now JDK6 users can turn their normal POJO in to web services and deploy it with ease without getting to deal with different web services stack. For starting from wsdl or contract first approach there are many WSDLs out there, such as ebay, salesforce.com etc. which are plain web-services WSDLs. You would simply run wsimport that comes with JDK. Before JDK6 one had to download some webservices toolkit and learn how to use just to get moving. I think its a great thing and will solve many users problems. For a complete end to end solution with security etc. you would typically get some container provided web services stack and achieve all the security, policy, reliability and so on. And yes, for the latest JAXWS with latest bells and whistles, they can always use JDK override mechanism:-)
  109. JAX-WS in Java6 is a great idea![ Go to top ]

    And I say that because of the reasons listed here: http://blogs.sun.com/arungupta/entry/web_services_native_support_in
  110. Arun. That is what I was saying before. What does "Native Support" mean? The actual concept is wrong. Native support is not achieved by plug-in the best standard's implementation into the JRE. Rather, that is a shortcut to avoid the pain of choosing, deploying and working with a third party stack. It helps, sure it does, to shorten the deployment time, but I'm not completely sure it is a native support. It would require: 1. Adding XML as a native type in Java. 2. Adding messaging as either a native type or as a supported structure or a new base object. 3. Adding a new type of "remote" call (ugh, RPC). 4. Adding a new type of interface, called "Service". All these in the language. That is native. William Martinez Pomares
  111. Arun.
    That is what I was saying before. What does "Native Support" mean? The actual concept is wrong. Native support is not achieved by plug-in the best standard's implementation into the JRE. Rather, that is a shortcut to avoid the pain of choosing, deploying and working with a third party stack.

    It helps, sure it does, to shorten the deployment time, but I'm not completely sure it is a native support. It would require:
    1. Adding XML as a native type in Java.
    2. Adding messaging as either a native type or as a supported structure or a new base object.
    3. Adding a new type of "remote" call (ugh, RPC).
    4. Adding a new type of interface, called "Service".
    All these in the language. That is native.

    William Martinez Pomares
    Hi William, It is funny that you should mention language support. Those of you who have read my posts won't be surprised to hear me say again, that the problem with WSDL is that it is the wrong approach steming from a misconception of what OO is all about. Objects are ment to communicate through messages, not fixed static APIs or RPC or a virtual function call. What we have again is the C++ approach to object communication turning up on the web. So WS-* is CORBA for the web, and WSDL is IDL for the web. All this fixed API, RPC stuff leads to brittle interfaces that break every time you want to make a benign change. What is needed is a way to seperate the concerns of interface and service, which is what messaging does. Another approach to gaining a high level of decoupling is reducing the interface to a small generic set of verbs, a uniform connector as used in REST. With REST the specific service request is part of the data, not the interface, with messaging the same. These ideas aren't new, and CORBA, COM etc have been shown to fail, yet we are busy re-inventing them as WS-*, why? My guess is that the vendors know all of this, but there is more money in complex RPC style WS-* standards, then in simpler approaches like Messaging and REST. Paul.
  112. Hi Paul. I celebrate your posting. Please read mine as a "sarcastic" one, if fits, since the idea of adding JAX-WS to Java6 was mentioned as "Native Support" and I wanted to depict what that "Native" would mean. Actually, WS concept is to be supported and not tweaked to be assimilated by language, a Native Support may require changing the language to support WS. And you are totally right, object's conception of a package with methods (procedures) is not the purest one. Reading my list again, I will change several things: Messaging would need to be a dynamic structure (differentiate between calling an object's procedure and sending a message to it), differentiate between Service and Interface, etc.
  113. Hi Paul.
    I celebrate your posting. Please read mine as a "sarcastic" one, if fits, since the idea of adding JAX-WS to Java6 was mentioned as "Native Support" and I wanted to depict what that "Native" would mean.

    Actually, WS concept is to be supported and not tweaked to be assimilated by language, a Native Support may require changing the language to support WS. And you are totally right, object's conception of a package with methods (procedures) is not the purest one.

    Reading my list again, I will change several things: Messaging would need to be a dynamic structure (differentiate between calling an object's procedure and sending a message to it), differentiate between Service and Interface, etc.
    Hi William, I saw the sarcasm :^) What made me smile is the irony of adding native support for an approach to object communicaton that stems from a language limitation in the first place. I sympathise with you, what do you tell your students? I'm really perplexed at the poor grasp of core concepts that is rife in our industry. Here is a link to an interesting post by Alan Kay that tries to set the record straight. Yet we still continue to make the same mistakes again, and again! http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html Paul.
  114. Re: JAX-WS in Java6 is a great idea![ Go to top ]

    Here is a link to an interesting post by Alan Kay that tries to set the record straight.
    Great... you got a mention of Alan Kay in again. Don't forget to include Croquet.
  115. stop whining[ Go to top ]

    i am glad that they have the WS support in Java6, even if it is not the perfect way. Believe me this is better then half assed non documented Xfire or wannabe axis.
  116. REST[ Go to top ]

    For simple messaging type access, I just use a REST approach. i.e. roll-your-own XML format. You can still use xml schemas or DTDs to verify message formats and its a billion times simpler/easier to use. WS-* is a completely over-engineered steaming pile of the proverbial.
  117. This is really good news specially for making web service clients. Together with Java WebStart this enables really light weight but still powerful standalone applications which can be launched online.
  118. I believe THE reason why it's bad to bundle, is that web services are still evolving today. Let's take a look at non-sun standards: 3DES, SMTP, XML, JPG, SOAP, PNG, WMV. The great thing about the first 3 are, they are set in stone so to speak. There's nothing to change anytime soon. DTD and Schema have changed very little for a very long time. SMTP I wouldn't dare think can change w/o a major uproar. PNG is still a fairly new standard, but it has proven to not change in so very long. It should probably be queued to be put in the JRE if not already. WMV and SOAP are still evolving. WMV more so because it's MS. They are competing to making WMV the best of the best, and are changing it as they go along. Over the past ten years, seven or eight different changes have occurred. They are not forwards compatible. SOAP is kinda forward compatible, but due to the flexibility of XML, it is still changing. WS-Addressing, WS-Security and so on. It isn't set in stone, so why include it in the JRE when it may change in the next year or two? The politics of changing SOAP are not as serious as say, changing the format of SMTP, it is almost OK to continue evolving it. It's understood that it's not perfect and has ways to go. Give it more time.