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: BGB / cr88192 on 2 May 2010 22:36 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4bdcd1f8$0$276$14726298(a)news.sunsite.dk... > 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. > yeah... a lot of ZIP tools will automatically convert known text formats. failing this, the chain of events usually goes about like: open file in notepad, see that it is screwed up; summon wordpad to fix problem (usually via "Open With", click save button, exit); open with notepad again, problem solved... this doesn't usually take more than a few seconds, in the rarity it happens... (or they can use "shell nojutsu" if there are a whole lot of them and the "open with" ritual would get tedious...). OTOH, one can also use a different editor (I have little idea why MS never really bothered with LF-only line-ending support, as I wouldn't think this would be much more than maybe a few lines of code, but oh well, whatever...).
From: BGB / cr88192 on 2 May 2010 22:42 "Eric Sosman" <esosman(a)ieee-dot-org.invalid> wrote in message news:hrjvg0$su3$1(a)news.eternal-september.org... > On 5/1/2010 8:38 PM, Tom Anderson wrote: >> [...] >> 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. >> Declaring that all files must be converted on import is a complete >> non-starter. > > Declaring that all programs must recognize (and perhaps > generate) all the line-demarcation conventions of all systems > everywhere is a Hell of a lot less practical. > > I have, personally, actually used systems that marked > line boundaries > > - With a trailing LF > - With a trailing CR > - With a trailing CR LF pair > - With a leading CR and a trailing LF > - With a leading count and possibly a trailing pad > - With a leading count plus other metadata and a possible pad > - With no per-line data whatsoever > > I'm willing to wager a modest sum that you, personally, have > *never* written a program that can deal with all of even this > limited repertoire. Care to name an amount? > I have not usually seen any others than: LF CR and CR-LF... this would seem to be all of them, and I suspect CR is falling into oblivion (since OSX switched to LF...). or such...
From: Arne Vajhøj on 2 May 2010 22:43 On 02-05-2010 22:42, BGB / cr88192 wrote: > "Eric Sosman"<esosman(a)ieee-dot-org.invalid> wrote in message > news:hrjvg0$su3$1(a)news.eternal-september.org... >> On 5/1/2010 8:38 PM, Tom Anderson wrote: >>> [...] >>> 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. >>> Declaring that all files must be converted on import is a complete >>> non-starter. >> >> Declaring that all programs must recognize (and perhaps >> generate) all the line-demarcation conventions of all systems >> everywhere is a Hell of a lot less practical. >> >> I have, personally, actually used systems that marked >> line boundaries >> >> - With a trailing LF >> - With a trailing CR >> - With a trailing CR LF pair >> - With a leading CR and a trailing LF >> - With a leading count and possibly a trailing pad >> - With a leading count plus other metadata and a possible pad >> - With no per-line data whatsoever >> >> I'm willing to wager a modest sum that you, personally, have >> *never* written a program that can deal with all of even this >> limited repertoire. Care to name an amount? >> > > I have not usually seen any others than: > LF > CR > and CR-LF... > > this would seem to be all of them, and I suspect CR is falling into oblivion > (since OSX switched to LF...). > > or such... There is a world beyond MS and *nix. Arne
From: Jim Janney on 2 May 2010 22:49 Arved Sandstrom <dcest61(a)hotmail.com> writes: > Lew wrote: >> Arved Sandstrom wrote: >>>> A lot depends on exactly what it is that people are writing. If I was >>>> writing a Linux device driver in C I'd be cool with vim. But these days, >>>> where I have to deal with .NET or J2EE web apps with thousands of source >>>> files, I'd be an imbecile to try and do that with emacs. >> >> Arne Vajhøj wrote: >>> Emacs is pretty close to an IDE. >>> >>> But I don't know how good its Java and C# support is though. >> >> For C and C++, given that emacs integrates source editing, >> compilation, linking and debugging (synchronized with source >> listings), "close" isn't accurate - emacs is an IDE. >> >> I have not found it as useful for Java. >> > I agree, for some languages like C or C++ emacs _is_ an IDE. A prof of > mine wrote a fairly large C++ tool > (http://gri.sourceforge.net/index.php) using emacs, and he would have > been doing everything from within emacs. Depending on how much a > person's emacs has been tooled up it's a mistake to call it a text > editor. > > This is a fairly representative discussion regarding emacs vs Eclipse > for Java: > http://stackoverflow.com/questions/689544/is-emacs-useful-compared-to-eclipse-programming-java. > > > I don't doubt that there are some very good Java developers out there > who use nothing but emacs. If I used nothing but emacs, had it > thoroughly tooled up, knew all my shell mantras and had shell scripts > available to duplicate what a lot of Eclipse commands do, and had an > encyclopedic knowledge of the Java APIs for the areas that I'm working > in, I'd be just as fast as if I were using Eclipse. > > AHS At one time I did a lot of coding in Emacs Lisp, using Emacs of course, and for that Emacs was a very good IDE indeed, as good as anything I've used. Which leads me to speculate that for reasonably dynamic languages (Java and Lisp and C# but not C or C++) the best IDE is one written in the target language. For example, I really expect any Java IDE to take advantage of the reflection API, and that's easiest done from Java (or at least some JVM-based language). -- Jim Janney
From: Lew on 2 May 2010 23:53
On 05/02/2010 09:56 PM, Arne Vajhøj wrote: > On 02-05-2010 16:11, Lew wrote: >> On 05/02/2010 03:18 PM, Eric Sosman wrote: >>> On 5/2/2010 2:27 PM, Lew wrote: >>>> Arved Sandstrom wrote: >>>>> Fortunately "may not" is one of the modal negatives that has a fairly >>>>> unambiguous meaning, as in, "not allowed". That doesn't mean that a >>>>> lot >>>>> of people don't use it incorrectly, though. >>>> >>>> "Correctly" according to you. I've heard "may not" to mean "might not" >>>> my entire life. >>> >>> "Mom, can I use the car?" >>> >>> "You mean `may'." >>> >>> "Sorry. Mom, may I use the car?" >>> >>> "No, you may not." >> >> Your point may not have been clear here. What are you trying to say? > > That "may not" can have a meaning as "absolutely not". That is a pointless point since it never was in dispute. -- Lew |