Do you suggest me using IDE when I'm learning JAVA
in [Java Help]
|
Prev: call jni function dynamically without getting a JNIEnv handleas an argument.
Next: Encoding issue on my jsp page
From: Arved Sandstrom on 1 May 2010 21:07 Arne Vajh�j wrote: > On 29-04-2010 05:18, Arved Sandstrom wrote: >> Arne Vajh�j wrote: >>> On 28-04-2010 20:12, Arved Sandstrom wrote: >>>> Up until not so long ago I recommended making use of a text editor for >>>> initial basic learning. Now that I've really thought it though, I >>>> see no >>>> point in using anything but a good IDE. An IDE provides assistance in >>>> entering code, and there's nothing wrong with that. >>> >>> There is nothing wrong with the code typing assistance. >>> >>> But IDE from day 1 often result in people that do not know >>> anything about how to run things outside the IDE. >> >> That's entirely possible, that some people will have barely any grasp of >> how to work outside the IDE. If we discount developers leaving the IDE >> fro time to time to use a word processor or web browser, and also >> include the ability of the IDE to call up server consoles and what not, >> then these days with the latest IDEs a person can likely get away with >> using the IDE for everything and not suffer. > > Oh - the developer may not suffer, but all the people that has > to do the final packaging, QA support and production support that > the developer can not help with because the does not understand > how the output of his development is used will suffer. > > Arne That's true, but that's still not the IDE's fault, because you can do everything correctly from inside the IDE. If we're talking about J2EE apps, for example, and where I have the power to make suggestions that are followed, I suggest (strongly) to the development teams I advise that developers are 100% responsible for ensuring that EARs deploy properly, whether in a CI environment in development, or in testing. There are often unavoidable differences between dev/test deployments and final production deployments, but we try to minimize these so that ops support people have as little to do in server deployment plans as possible. This way the developers are accountable for everything about the packaged EAR. To use Sun's terminology I prefer it when the developers are both the "component providers" and the "application assemblers". And that in their role as the assemblers they make sure that the "deployers" don't waste time figuring out why class a.b.c.Whatzit isn't on the classpath. AHS
From: Arne Vajhøj on 1 May 2010 21:14 On 01-05-2010 20:38, Tom Anderson wrote: > On Sat, 1 May 2010, Arne Vajh?j wrote: >> On 28-04-2010 08:43, Tom Anderson wrote: >>> On Tue, 27 Apr 2010, Arne Vajh?j wrote: >>>> On 27-04-2010 14:55, Lew wrote: >>>>> cr88192 wrote: >>>>>> anymore, I typically just do coding (in general) via the mix of >>>>>> Notepad, >>>>> >>>>> Notepad is very bad for Java programming because most extant versions >>>>> don't handle Unicode and they don't like cross-platform line endings. >>>> >>>> Notepad has supported Unicode since at least Windows XP from 2002. >>>> >>>> There are no such a thing as cross-platform line endings. >>>> >>>> It is true that notepad only supports the Windows CR LF, which >>>> means that it does not work when text files are moved as binary >>>> files from *nix. >>>> >>>> But instead of blaming notepad then people should transfer the >>>> files correctly. >>> >>> Rubbish. Should they unpack every jar they move across and see if it has >>> text files in, so they can convert them? Should they then have to >>> magically re-sign any sealed packages whose contents have changed? >> >> Given that notepad does not support editing of text files inside jar >> files, then there are absolutely no point in that nor any relevance >> for the discussion. > > What? Where does the idea of editing files inside JAR files come into this? Well: - I said that files should be converted to local line format for editing - you suggested that would mean extracting changing and repacking jar files Assuming there is a correlation between the two then that must be about editing files inside jar files. > On any platform, you may find yourself confronted by files with any kind > of line ending at any time, which have arrived from via any route. It is the responsibility of the transferring mechanism to ensure that text files arrive in a valid text format at the receiver. Let me guess: you have only worked with file systems with delimited files and no meta information about line format. Because when you have meta data about the line format instead of the "let us guess based on whether we see a lot of LF's or CRLF's", then the receiver had to get it right. > Declaring that all files must be converted on import is a complete > non-starter. The FTP protokol, the ZIP format etc. were designed to solve that problem. Apparently those people do not consider it a non-starter. Arne
From: Arne Vajhøj on 1 May 2010 21:16 On 01-05-2010 21:07, Arved Sandstrom wrote: > Arne Vajh�j wrote: >> On 29-04-2010 05:18, Arved Sandstrom wrote: >>> Arne Vajh�j wrote: >>>> On 28-04-2010 20:12, Arved Sandstrom wrote: >>>>> Up until not so long ago I recommended making use of a text editor for >>>>> initial basic learning. Now that I've really thought it though, I >>>>> see no >>>>> point in using anything but a good IDE. An IDE provides assistance in >>>>> entering code, and there's nothing wrong with that. >>>> >>>> There is nothing wrong with the code typing assistance. >>>> >>>> But IDE from day 1 often result in people that do not know >>>> anything about how to run things outside the IDE. >>> >>> That's entirely possible, that some people will have barely any grasp of >>> how to work outside the IDE. If we discount developers leaving the IDE >>> fro time to time to use a word processor or web browser, and also >>> include the ability of the IDE to call up server consoles and what not, >>> then these days with the latest IDEs a person can likely get away with >>> using the IDE for everything and not suffer. >> >> Oh - the developer may not suffer, but all the people that has >> to do the final packaging, QA support and production support that >> the developer can not help with because the does not understand >> how the output of his development is used will suffer. > > That's true, but that's still not the IDE's fault, because you can do > everything correctly from inside the IDE. But there are often no IDE available at all on the test and production systems. > If we're talking about J2EE apps, for example, and where I have the > power to make suggestions that are followed, I suggest (strongly) to the > development teams I advise that developers are 100% responsible for > ensuring that EARs deploy properly, whether in a CI environment in > development, or in testing. There are often unavoidable differences > between dev/test deployments and final production deployments, but we > try to minimize these so that ops support people have as little to do in > server deployment plans as possible. This way the developers are > accountable for everything about the packaged EAR. > > To use Sun's terminology I prefer it when the developers are both the > "component providers" and the "application assemblers". And that in > their role as the assemblers they make sure that the "deployers" don't > waste time figuring out why class a.b.c.Whatzit isn't on the classpath. I agree on that. Which I think some command line knowledge is a must for developers. Arne
From: Arne Vajhøj on 1 May 2010 21:28 On 01-05-2010 20:42, Tom Anderson wrote: > On Sat, 1 May 2010, Arne Vajh?j wrote: >> On 28-04-2010 12:40, Tom Anderson wrote: >>> I don't know a single good developer who develops on Windows. >> ... >>> I'm sure good developers who use Windows exist, but *everyone* i know >>> who's worth their salt uses either a Mac or Linux. >> >> Maybe you don't know companies where the company decide what OS their >> employees run and where the choice of OS is Windows. > > I do, and indeed my company is contracting for one at the moment. I use > a Windows machine every day, although only as an NX terminal to get > access to a virtual machine running Linux. > >> But that tells more about your level of experience than the Java world. > > I should have phrased it better: i don't know a single good developer > who develops on Windows by choice. Apart from Mike Schilling, although i > couldn't really say i know him. Ah - that is slightly different. But I would still expect there to be some Windows users. Of course it is difficult to know who you know and who you consider good programmers. But I would expect Jon Skeet to prefer writing his Java code at Google on Windows. >>> As for deployment, i've been involved in exactly one project that was >>> planning to deploy on Windows. As far as i know, that project is still >>> in the process of bursting into flames and dying, although that's got >>> little if anything to do with its target platform. >> >> A recent survey showed the following target platforms for Java EE: >> >> Window 57% >> Redhat & Centos 35% >> SUSE 12% >> Other Linux 16% >> Solaris 18% >> AIX 14% >> HP-UX 5% >> Other 7% >> No answer 18% >> >> (it adds to a lot more than 100% because many deploy on multiple >> platforms) > > Interesting. I'm really surprised by that. Java does not necessarily mean not-Windows. Arne
From: John B. Matthews on 1 May 2010 21:33
In article <4bdcc66f$0$277$14726298(a)news.sunsite.dk>, Arne Vajhøj <arne(a)vajhoej.dk> wrote: > On 01-05-2010 10:25, John B. Matthews wrote: > > In article<hrghdl$35u$1(a)news.albasani.net>, > > "BGB / cr88192"<cr88192(a)hotmail.com> wrote: > >> Java imposes the one-class-per-file restriction > > > > More specifically, one public, top-level class per file. There can be an > > arbitrary number of package-private and nested classes. > > > > <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6> > > This just say: > > <quote> > When packages are stored in a file system (§7.2.1), the host system may > choose to enforce the restriction that ... > </quote> > > But SUN's implementation (and probably all other common implementations) > of Java compiler does enforce. Interesting. In contrast, "a system that uses a database to store packages may not enforce a maximum of one public class or interface per compilation unit." <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#37739> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> |