Bugzilla – Full Text Bug Listing
| Summary: | support mylar running on a 1.4 JRE | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | ekuleshov, gunnar, ifoox, jed.anderson, overholt, stephan |
| Version: | 0.3 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Mik Kersten
So, I have compiled everything with retroweaver and here are a couple of things that we will need to change since Java 1.4 doesn't support them. In bugzilla, we use the Proxy class which doesn't seem to exist Collections.emptyList() method doesn't exist Other constraints: - need to included retroweaver.jar [41K] in Mylar core and export it for other plug-ins - license is Apache which is compatible with EPL - won't be able to support proxies in 1.4 This is enough for us to go ahead and try to update the code to be compliant with the minor retroweaver limitatins, and to create a build process that uses retroweaver for creating a 1.4 distribution (new bug 108291). We still need to figure legal issues about distributing the Retroweaver JAR. Please note that using retroweaver does not necessarily make the situation any better for Linux distributions. While we have a 1.5-level bytecode compiler (ecj), none of the big distros (or any that I know of, for that matter) are shipping 1.5-level class libraries so unless it's just language features that are being used, compilation is out of the question. That's good news about ecj. It is feasible that Mylar move back to JDK 1.4 API usage, but definitely not convenient. Note that Eclipse 3.2 will require 1.5. Is there an ETA for a 1.5 JDK/JRE for RedHat? If "Proxy" is java.lang.reflect.Proxy, then it is in 1.4 (it was added in 1.3). For emptyList(), you can use Collections.EMPTY_LIST. This is the same thing, really, just without a generic type. We're hard at work making gcj support 1.5. I think our current plan will have it being ready next summer. (Though of course we don't guarantee that...) "Proxy" is the http proxy server stuff, used for connecting to Bugzilla servers and for uploading. Replacing that would likely involve an additional dependency (e.g. on Apache proxy stuff, assuming they have that), which would trigger a minimum 6-week process to get approved by eclipse.org But that aside, it sounds like going with ecj would yield a similar result to running retroweaver over our bytecodes, because retroweaver requires 1.4 libraries and complains about any 1.5 usage. I'm reopening this report since the issue is still open. However, there will need to be more input from users needing to run Mylar on 1.4 VMs before it gets prioritized over the other open issues. (In reply to comment #6) > But that > aside, it sounds like going with ecj would yield a similar result to running > retroweaver over our bytecodes, because retroweaver requires 1.4 libraries and > complains about any 1.5 usage. What do you mean by "going with ecj"? ecj is just the Eclipse compiler (we split it out for use as our bytecode compiler ATM). retroweaver is not an option for us because we need to be able to build the bytecode first (which we can't do if you're using 1.5 library stuff but *might* be able to do if you're just using language features). I don't have any time to commit to this, but perhaps someone else does. Thanks for keeping the issue open. Oops, got confused about "ecj" because I hadn't heard of the Eclipse headless compiler referred to as that before. Marking the issue as helpwanted in case anyone is interested in taking this on. I've been 1.4-ifying org.eclipse.mylar.bugzilla.core today. I've got a big patch and it wasn't that difficult. The only remaining issue (that I can see) is this one: (In reply to comment #6) > "Proxy" is the http proxy server stuff, used for connecting to Bugzilla servers > and for uploading. Replacing that would likely involve an additional > dependency (e.g. on Apache proxy stuff, assuming they have that), which would > trigger a minimum 6-week process to get approved by eclipse.org I don't know what we can do here. I'll have a look at what the Platform/Team plugin does in this case. (In reply to comment #9) > > "Proxy" is the http proxy server stuff, used for connecting to Bugzilla servers > > and for uploading. Replacing that would likely involve an additional > > dependency (e.g. on Apache proxy stuff, assuming they have that), which would > > trigger a minimum 6-week process to get approved by eclipse.org > > I don't know what we can do here. I'll have a look at what the Platform/Team > plugin does in this case. Not a long time ago I filled in a request for proxy/tunnel support for Eclipse platform. https://bugs.eclipse.org/bugs/show_bug.cgi?id=119278 You can reuse proxy implementations from jcsh library. It is also used in one of the Team/CVS plugins and there had been some discussion to package it as a standalone plugin to be reuseable. Cool, let me know what you find on the proxy stuff. mylar.bugzilla.core may be fine to be keep 1.4 compatible (but note that mylar.bugzilla.ui is a different story because it depends on mylar.tasklist). A cahnge to the proxy stuff would have to come with a test case because there is no automated test for that right now and it's way too easy to break. Note that the Bugzilla stuff has the worst unit test coverage of all the Mylar components becayse it was originally developed in a non-TDD way :| It's no longer possible to commit dependencies without eclipse.org approval (6 week wait, sigh). Is jcsh under EPL? That could make it faster. Andrew, if you find out whehter the classes are accessible via the Team/CVS plug-in that would be great. Another place to check is the update site stuff, which honors proxy settings. (In reply to comment #12) > It's no longer possible to commit dependencies without eclipse.org approval (6 > week wait, sigh). Is jcsh under EPL? That could make it faster. Andrew, if > you find out whehter the classes are accessible via the Team/CVS plug-in that > would be great. Another place to check is the update site stuff, which honors > proxy settings. But it is already committed inder one of Team/CVS plugins. License is "BSD style" - http://www.jcraft.com/jsch/LICENSE.txt Unfortunately I would still have to oficially ask eclipse.org before committing it. But at least we would have a strong case for not triggering a review process. Jed: you voted for it--does that mean that a portion of the MyEclipse community is not yet able to upgrade to a 1.5 JRE? All: are there still other platforms on which running a 1.5 JRE is a showstopper? (In reply to comment #15) > All: are there still other platforms on which running a 1.5 JRE is a > showstopper? GNU Classpath-based "JVMs" are not yet fully 1.5; at least not those shipped with all distros. Andrew: do you have instructions for how to update those distros to 1.5? I'd like to add that to the FAQ. (In reply to comment #17) > Andrew: do you have instructions for how to update those distros to 1.5? I'd > like to add that to the FAQ. There are no instructions for many of the distros. I believe Debian may ship GNU Classpath's generics branch but they're quite possibly the only ones. Sorry I can't offer more. I voted for this because Eclipse 3.2 is targeting both JDK 1.4 and Java SE 5 . I feel plugins that are built on top of 3.2 should adhere to this standard as well. http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html Andrew: No, Debian hasn't packages for the generics branch yet. Only inofficial packages. So, Debian has the same problem(including Ubuntu). So are the JavaONE announcements going to have a positive impact on how quickly we see Java 5 in the Linux distros? (In reply to comment #21) > So are the JavaONE announcements going to have a positive impact on how quickly > we see Java 5 in the Linux distros? Not in the free distros. We still have no plans to support 1.4, since our 1.0 APIs are all generics-aware and that provides both the framework and its client with substantial modularity benefits. Feedback to date has not indicated the lack of 1.4 support being a showstopper to the point where it is worth sacrificing generics. Also, the end of life for JDK 1.4 is approaching (once Java 7 ships). Instructions for getting set up on 1.5 are here: http://wiki.eclipse.org/index.php/Mylar_User_Guide#Download_and_configure_Java_5_or_6 If there are any special instructions for any of the Linux distros we should add them there. |