This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Features like Add {business, finder, select,..} method, Call EJB, etc. do not work if the source in which they are added contains generics. This is because j2ee/ejbjarproject module uses src hierarchy and the src-jmi bridge does not support code generation for source with generics.
Starting immediately
Martin, perhaps you should hold on. Maybe we will tweak the bridge so that it will allow what you need...
OK, would be nice. Thanks.
From the J2EE 1.4 spec lead: > 1/ if a J2EE EAR file contains classes that makes usage of J2SE 5.0 features like generics, is it J2EE 1.4 compliant? No. That is, it's not portable to any arbitrary J2EE 1.4 product. > 2/ On a related area can an J2EE 1.4 EJB declare business methods with generics as parameters? If yes, I guess the method signature is used in ejb-jar.xml has to correctly reflect this... if necessary when declaring security settings. No. > I read from http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf > > in J2EE 6.1.1: ... . v1.4 (J2SE) > and same in J2EE 2.3.1 > > but I didn't see the explicit statement that the J2EE apps *must not* use lang feature and APIs in J2SE later than 1.4. It said J2EE *containers* *must* provide at least J2SE 1.4. > > Also if we interpret the spec that "what we produce (meaning J2EE apps incl. web apps) must be runnable in any J2EE 1.4 compliant container", then we have another trouble: we cannot compile the classes against JDK 1.5, using -source 1.4 -target 1.4 is not enough, the rt.jar must come from J2SE 1.4. Correct. > It seems to me the spec puts the requirements on the container but does not put reqs on the apps which will run in the container. There are places where the spec says apps *must not* do certain things. But generally it's a matter of portability. Knowing what the container must do tells you what you can depend on in a portable app. If you depend on something that is not in the list of things a container must do, in general you're just non-portable. There are only a few places where the app would be "illegal".
proposed solution: Assume the user has J2SE 1.5 as the default J2SE platform. If there is also J2SE 1.4 platform registered in IDE we should set it for this project and display a warning in project wizard (EJB/Web): "J2EE 1.4 specification is compliant with J2SE 1.4. The "J2SE 1.4.2_6 (name of platform)" will be selected as target platform for this project. You can change this in project properties." If there is no J2SE 1.4 platform display a different warning: "J2EE 1.4 specification is compliant with J2SE 1.4. Some features of J2SE 1.5 may not work in J2EE 1.4 environment. The source level of this project will be set to 1.4. You can change this in project properties." The exact wording should be provided by docs people, of course. Maybe replace "is compliant" with "guarantees". With that there can still be minor problems, code completion will run from j2se 1.5 rt.jar so the code will not be 100% 1.4 compliant, but I think this is ok - user error I'd say. Better then forcing the user to download and install j2se 1.4 if she only has j2se 1.5. We should add more detailed warnings into project properties for the Source Level and Java Platform combo boxes. I can propose the text for those. Then we will use the switch for openide.src to make things work as good as we can at this point. We can do some restrictions in refactoring to prevent use of generics in places where it is obviously wrong, if we have time. The user has been warned but not limited, out of the box everything will work. In addition to that: There is some more info about cross-compilation here: http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html#crosscomp-options If folks want to dig into this issue a bit more. Note that -source 1.4 is not enough to produce 1.4 safe code.
Solution on level of EJB project area - reassigning to Andrei :-)
Jirko, please comment on this. I need to know: - the exact wording of the warnings in the wizards and in the customizer - if the warnings will be JLabels or dialog boxes. The warnings in the customizer will be more detailed, so probably we should use dialogs for them?
I've updated the UI specification of the New Project Wizards in a way to warn the users about using JDK 1.5 with J2EE 1.4 projects. The links are here: http://web.netbeans.org/nonav/doc/webapp-project-ui-spec-promoe.html#Step_2_New_Web_Application http://web.netbeans.org/nonav/doc/webapp-project-ui-spec-promoe.html#Step_2_New_Web_Application_With_Existing_Sources http://j2ee.netbeans.org/nonav/docs/ejb-module-project-ui-spec-promoe.html#Step_2_Name_And_Location http://j2ee.netbeans.org/nonav/docs/ejb-module-project-ui-spec-promoe.html#Step_2_Existing_Sources_Name_And_Location http://j2ee.netbeans.org/nonav/docs/enterprise-app-project-ui-spec-promoe.html#Step_2_Name_And_Location http://j2ee.netbeans.org/nonav/docs/enterprise-app-project-ui-spec-promoe.html#Step_2_With_Existing_Sources_Name_And_Location
Created attachment 20983 [details] Commit log for the web project
Created attachment 20996 [details] Commit log for the EJB project
The changes in the ear project will have to be reviewed by Vince. I will likely commit them tomorrow.
I just tried the web wizard in the latest continuous build, and there are some display problems on Win2000/JDK 1.5.0 - the panel does not fit on the screen. Attaching a screenshot.
Created attachment 21008 [details] The panel of the wizard with the problems
There is a bug in TempateWizard or in NbPresenter that I will report. For now I tried to workaround, but it seems I have not been successful (well, at least not on Windows)...
Created attachment 21022 [details] Commit log for the ear project
Martine M, can you please turn the ability to write to JDK 5.0 sources through the src hierarchy bridge *on* by default? Please add a comment to this issue when you've done it. Thanks.
Dan will do it and let you know.
Done. Checking in ElementImpl.java; /cvs/java/src/org/netbeans/modules/java/bridge/ElementImpl.java,v <-- ElementImpl.java new revision: 1.32; previous revision: 1.31
Dane and Martine, thanks. Regarding the screenshot I attached previously: it appears that this is because I have my display settings set up to 120%, so everything is bigger than unually. I am not sure if this is too important to support. Either way, Andrei says that we still have the problem with size - preferred size of the panel is set explicitly; otherwise the panel would be too big on Linux. Simply, THE PANEL IS TOO BIG. We may need to find a way how to eliminate some things from the panel, assigning to Jiri Kopsa. Jirka, please advise and treat this as a priority. Thanks.
There two solutions. 1. QUICK SOLUTION Move the whole recommendation messages to Help and provide only a warning message if the user tries to create a problematic project. The message may look like this: If only JDK 1.5 is present: Recommendation: Souce Level 1.4 should be used in J2EE 1.4 projects. If JDK 1.5 is default but JDK 1.4 is available: Recommendation: JDK 1.4 and Source Level 1.4 should be used in J2EE 1.4 projects. 2. GOOD SOLUTION Move the "Platform stuff" to a NEW STEP. We need to do this anyway in the "New Web Project with Existing Sources" (agreed to do it in promo f). In that wizard it might happen that the user needs to go back from step #3 to step #2 to change the j2ee version. This happens if the web root is not found in the guessing process. Optimal workflow of that wizard would be then: Step #2: Location Step #3: Web Root (or Configuration Files Folder in case of EJB), Source Packages, Libraries Step #4: Platform (i.e. server, version, JDK, source level) These changes would apply to the following wizards: New Web Application New Web Application with Existing Sources New EJB Module with Existing Sources New EJB Module Which way do we want to go? Expecting the quick way... Assigning to Peter J. to decide. And adding UI keyword and docs (sorry guys for doing this so late).
We agreed on the quick solution #1. I'll update the UI spec later.
Checking in Bundle.properties; /cvs/web/project/src/org/netbeans/modules/web/project/ui/wizards/Bundle.properties,v <-- Bundle.properties new revision: 1.54; previous revision: 1.53 done Checking in Bundle.properties; /cvs/j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/ui/wizards/Bundle.properties,v <-- Bundle.properties new revision: 1.23; previous revision: 1.22 done Checking in Bundle.properties; /cvs/j2ee/utilities/src/org/netbeans/modules/j2ee/common/ui/wizards/Bundle.properties,v <-- Bundle.properties new revision: 1.12; previous revision: 1.11 done
There is still not enough space for the web wizard with existing sources panel. We need to reduce it by a couple of pixels, or live with it (the wizard resizes when displaying the panel, so all the UI widgets are visible).
Let's try to find out, where we can save some space. I'm attaching WinXP screenshots. The initial dimensions of the wizard are 729x501 pixels. The WebApp with Existing Sources resizes to 729x545 pixels. (+44px) The EJB Module with Existing Sources resized to 729x531 pixels. (+30px) Could you Andrei provide the dimensions of the wizard running on your system? Thanks!
Created attachment 21141 [details] New EJB Module With Existing Sources - Step #2
Created attachment 21142 [details] New Web Application With Existing Sources - Step #2
Jirko, please update. I integrated the short recommendations that we agreed upon yesterday. The expanding web wizard with ex. src. I'm describing in my last comment refers to the wizard with the short recommendations. Sorry for not making this more clear.
With the shortened messages the only wizard that changes its height is "New Web Project with Existing Sources". It resizes by 12 pixels on Windows XP (with standard fonts size). I think we're fine with the current state for now. I'm closing this issue and filling an enhancement - #57117. http://www.netbeans.org/issues/show_bug.cgi?id=57117
verified