Bugzilla – Full Text Bug Listing
| Summary: | [preferences] NumberFormatException: For input string: "container" when creating new Java project | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | John <M8R-sgiphk> | ||||||||||
| Component: | UI | Assignee: | Dani Megert <daniel_megert> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | critical | ||||||||||||
| Priority: | P3 | CC: | daniel_megert, deepakazad, markus.kell.r, Michael_Rennie, pwebster, remy.suen | ||||||||||
| Version: | 3.7 | Flags: | daniel_megert:
review+
deepakazad: review+ Michael_Rennie: review+ |
||||||||||
| Target Milestone: | 3.7 RC4 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
John
Works fine fore me. Can you provide steps starting with a new workspace? Or can you attach your workspace here? Created attachment 196657 [details]
org.eclipse.jdt.launching.prefs
this file:
org.eclipse.jdt.launching.prefs
located in:
workspace\.metadata\.plugins\org.eclipse.core.runtime\.settings
Sorry but this doesn't help. We either need steps to reproduce the problem or a workspace where we can investigate the issue. ok, I will see what I can do about packing up the workspace ... :) Alrightie then, here's steps to reproduce: 0. Window->Show View->Error Log 1. switch to a new never-before-created workspace, do not copy settings from current one (obviously xD) 2. File->New->Java Project give project a name ie. "x" 3. JRE: select `Use default JRE (currently 'jdk1.6.0_25') 4. press Next at this point there should be 4 errors in Error Log (as described above) (no need to press Finish to create the project) let me know if this isn't enough, I also include the new (since it's different) org.eclipse.jdt.launching.prefs as attachment I don't think you'd need the workspace to reproduce this, but you'd probably(?) need at least(and maybe only) jdk6u25 Created attachment 196660 [details]
org.eclipse.jdt.launching.prefs
workspace\.metadata\.plugins\org.eclipse.core.runtime\.settings
Thanks! I can reproduce now. feel free to ignore this comment, it's mostly for stating the obvious --- also note, if you miss step 3, thus you'll be using the defaults: JRE: `Use and execution environment JRE: JavaSE-1.6` then the bug/error will not appear, and apparently the last selected option remains set for all future `new java project` wizards, thus I failed to specify the defaults(that were on my computer, considering it remembers the last selected ones) which I will do so now: Project name: can be anything (checked) Use default location: JRE: (selected) Use default JRE (currently 'jdk1.6.0_25') Project layout: (selected) Create separate folders for sources and class files Working sets: (unchecked) Add project to working sets Caused by fix for bug 338673. Created attachment 196665 [details]
Fix
Created attachment 196750 [details] Fix 2 (revert bug 338673) (In reply to comment #10) > Created attachment 196665 [details] [diff] > Fix The fix is problematic, since it still doesn't restore the symmetry between the encode and decode operations. E.g. when the UI string contains a + or something like %x, then the decoding with the URLEncoder can return wrong results or even fail with an IAE. Discussed this with Dani, and we think the safest fix at this point is to revert bug 338673 completely. That scenario is unlikely to happen in the real world. Users who work in a localized version of Eclipse that uses multi-byte characters typically also have a platform encoding that supports multi-byte characters (and then bug 338673 doesn't appear at all). I'll reopen bug 338673. Dani & Deepak, can you please review Fix 2 (which just reverts to NewJavaProjectPreferencePage.java 1.33)? I think that's the safest fix at this point. +1 for RC4. +1. Though you could leave in the changes to the comments. > +1. Though you could leave in the changes to the comments.
Yeah, but we're already in RC4, so reverting the whole file seems safer.
RISK: Very low. We revert the code to the pre-3.7M7 state. This brings back bug 338673, but that's a minor problem that we don't think will show up in practice (see bug 338673 comment 6). Mike, can you please give the last +1? +1 looks good. I did notice the addition of '//AW' at the top of the patch, not sure if that is intentional or not. Committed to HEAD. Verified in I20110602-1051. |