Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20864 > unrolled thread

question on java lang spec chapter 3.3 (unicode char lexing)

Back to article view | Back to comp.lang.java.programmer

Contents

  question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 00:20 -0800
    Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 00:24 -0800
      Re: question on java lang spec chapter 3.3 (unicode char lexing) Patricia Shanahan <pats@acm.org> - 2013-01-02 12:24 -0800
    Re: question on java lang spec chapter 3.3 (unicode char lexing) Lew <lewbloch@gmail.com> - 2013-01-02 11:16 -0800
      Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 19:55 -0500
        Re: question on java lang spec chapter 3.3 (unicode char lexing) Lew <lewbloch@gmail.com> - 2013-01-02 17:21 -0800
          Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 20:40 -0500
    Re: question on java lang spec chapter 3.3 (unicode char lexing) Roedy Green <see_website@mindprod.com.invalid> - 2013-01-02 11:17 -0800
      Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 19:56 -0500
        Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 17:27 -0800
          Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 17:32 -0800
          Re: question on java lang spec chapter 3.3 (unicode char lexing) Lew <lewbloch@gmail.com> - 2013-01-02 17:42 -0800
            Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 17:55 -0800
              Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 18:02 -0800
                Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 21:12 -0500
                  Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 18:16 -0800
                    Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 21:20 -0500
                      Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 18:22 -0800
                        Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 21:26 -0500
                          Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 18:27 -0800
                            Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 21:46 -0500
                              Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 20:41 -0800
                                Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:54 -0500
              Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 21:15 -0500
                Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-02 18:20 -0800
          Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 21:17 -0500
          Re: question on java lang spec chapter 3.3 (unicode char lexing) Patricia Shanahan <pats@acm.org> - 2013-01-02 22:33 -0800
            Re: question on java lang spec chapter 3.3 (unicode char lexing) "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-01-05 12:58 +0000
              Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-05 05:34 -0800
                Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-05 05:40 -0800
                Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:56 -0500
        Re: question on java lang spec chapter 3.3 (unicode char lexing) Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-03 21:14 +0000
          Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-03 17:51 -0500
            Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-03 20:54 -0800
              Re: question on java lang spec chapter 3.3 (unicode char lexing) Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-05 00:15 +0000
              Re: question on java lang spec chapter 3.3 (unicode char lexing) "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-01-05 13:03 +0000
                Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-05 05:25 -0800
                  Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:49 -0500
                    Re: question on java lang spec chapter 3.3 (unicode char lexing) "Aryeh M. Friedman" <Aryeh.Friedman@gmail.com> - 2013-01-06 23:26 -0800
              Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:44 -0500
    Re: question on java lang spec chapter 3.3 (unicode char lexing) Arne Vajhøj <arne@vajhoej.dk> - 2013-01-02 19:54 -0500

Page 1 of 3  [1] 2 3  Next page →

#20864 — question on java lang spec chapter 3.3 (unicode char lexing)

If I am lexer for Java in a 100% unicode environment (it already uses unicode for all internal representation of text) and 100% of the code that I will be lexing is from that environment do I need still deal with unicode escapes (\uXXXX) in real life [vs. theortically complete lexing]... assume that no code will be imported from non-unicode environments

[toc] | [next] | [standalone]

#20865

On Wednesday, January 2, 2013 3:20:12 AM UTC-5, Aryeh M. Friedman wrote:
> If I am lexer for Java in a 100% unicode environment (it already uses unicode for all internal representation of text) and 100% of the code that I will be lexing is from that environment do I need still deal with unicode escapes (\uXXXX) in real life [vs. theortically complete lexing]... assume that no code will be imported from non-unicode environments

Just a follow up this is for a Java to native (x86) compiler written in Java I am doing for fun (no practical purpose except for practice in compiler writing [not for school or work])

[toc] | [prev] | [next] | [standalone]

#20880

On 1/2/2013 12:24 AM, Aryeh M. Friedman wrote:
> On Wednesday, January 2, 2013 3:20:12 AM UTC-5, Aryeh M. Friedman
> wrote:
>> If I am lexer for Java in a 100% unicode environment (it already
>> uses unicode for all internal representation of text) and 100% of
>> the code that I will be lexing is from that environment do I need
>> still deal with unicode escapes (\uXXXX) in real life [vs.
>> theortically complete lexing]... assume that no code will be
>> imported from non-unicode environments
>
> Just a follow up this is for a Java to native (x86) compiler written
> in Java I am doing for fun (no practical purpose except for practice
> in compiler writing [not for school or work])
>

If this is just a fun exercise, you can choose to compile any subset of
Java you like, but don't call it a Java compiler. You just have to limit
the code you try to compile with it to the subset you have implemented.

In a compiler for practical use, you would have to deal with source code
that may have been written by others, so having coding conventions
against certain features such as the Unicode escapes would not help.

Patricia

[toc] | [prev] | [next] | [standalone]

#20876

On Wednesday, January 2, 2013 12:20:12 AM UTC-8, Aryeh M. Friedman wrote:
> If I am lexer for Java in a 100% unicode [sic] environment (it already uses unicode for all internal 
> representation of text) and 100% of the code that I will be lexing is from that environment do I need still 
> deal with unicode escapes (\uXXXX) in real life [vs. theortically complete lexing]... assume that no code 
> will be imported from non-unicode environments

What do you mean "have to deal with"?

If you mean to parse Java source, you have to be able to parse Java source. The JLS is the final 
authority on what that constitutes.

Being "in a 100% unicode [sic] environment" (whatever that's supposed to mean) does not excuse 
any responsibilities.

Nor does it obviate the need for the occasional "\uXXXX" in source.

However, I don't think the lexer deals with that. Unicode escape sequences are a precompile phenomenon. Everything is substituted before parsing starts.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20887

On 1/2/2013 2:16 PM, Lew wrote:
> On Wednesday, January 2, 2013 12:20:12 AM UTC-8, Aryeh M. Friedman wrote:
>> If I am lexer for Java in a 100% unicode [sic] environment (it already uses unicode for all internal
>> representation of text) and 100% of the code that I will be lexing is from that environment do I need still
>> deal with unicode escapes (\uXXXX) in real life [vs. theortically complete lexing]... assume that no code
>> will be imported from non-unicode environments
>
> What do you mean "have to deal with"?
>
> If you mean to parse Java source, you have to be able to parse Java source. The JLS is the final
> authority on what that constitutes.
>
> Being "in a 100% unicode [sic] environment" (whatever that's supposed to mean) does not excuse
> any responsibilities.
>
> Nor does it obviate the need for the occasional "\uXXXX" in source.
>
> However, I don't think the lexer deals with that. Unicode escape sequences are a precompile phenomenon. Everything is substituted before parsing starts.

Well - lexing happens before parsing so ...

Arne

[toc] | [prev] | [next] | [standalone]

#20890

Arne Vajhøj wrote:
> Lew wrote:
>>Aryeh M. Friedman wrote:
>>> If I am lexer for Java in a 100% unicode [sic] environment (it already uses unicode for all internal
>>> representation of text) and 100% of the code that I will be lexing is from that environment do I need still
>>> deal with unicode escapes (\uXXXX) in real life [vs. theortically complete lexing]... assume that no code
>>> will be imported from non-unicode environments
> 
>> What do you mean "have to deal with"?
>>
>> If you mean to parse Java source, you have to be able to parse Java source. The JLS is the final
>> authority on what that constitutes.
> 
>> Being "in a 100% unicode [sic] environment" (whatever that's supposed to mean) does not excuse
> > any responsibilities.
> 
>> Nor does it obviate the need for the occasional "\uXXXX" in source.
> 
>> However, I don't think the lexer deals with that. Unicode escape sequences are a precompile 
>> phenomenon. Everything is substituted before parsing starts.
> 
> Well - lexing happens before parsing so ...

So does writing source code. What's your point?

My point is that the lexer picks up after the substitution of Unicode sequences.
However, my point is wrong, and yours is right.

http://www.docjar.com/html/api/com/sun/tools/javac/parser/Lexer.java.html

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20896

On 1/2/2013 8:21 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Aryeh M. Friedman wrote:
>>>> If I am lexer for Java in a 100% unicode [sic] environment (it already uses unicode for all internal
>>>> representation of text) and 100% of the code that I will be lexing is from that environment do I need still
>>>> deal with unicode escapes (\uXXXX) in real life [vs. theortically complete lexing]... assume that no code
>>>> will be imported from non-unicode environments
>>
>>> What do you mean "have to deal with"?
>>>
>>> If you mean to parse Java source, you have to be able to parse Java source. The JLS is the final
>>> authority on what that constitutes.
>>
>>> Being "in a 100% unicode [sic] environment" (whatever that's supposed to mean) does not excuse
>>> any responsibilities.
>>
>>> Nor does it obviate the need for the occasional "\uXXXX" in source.
>>
>>> However, I don't think the lexer deals with that. Unicode escape sequences are a precompile
>>> phenomenon. Everything is substituted before parsing starts.
>>
>> Well - lexing happens before parsing so ...
>
> So does writing source code. What's your point?

That it being done before parsing does not imply not done by lexer.

> My point is that the lexer picks up after the substitution of Unicode sequences.
> However, my point is wrong, and yours is right.
>
> http://www.docjar.com/html/api/com/sun/tools/javac/parser/Lexer.java.html

I am not quite sure what that source code snippet shows.

But a lexer is something that converts from a stream of
source code to a stream of tokens.

Given that:
- the source code contains the escape sequences
- escape sequences get treated similar to real unicode
and if we assume that:
- the parser has not duplicated a ton of logic to handle
   a unicode token
then the conversion of escape sequences must either happen in
the lexer.

Whether it is a filter in front of the real lexer or more
deeply buried into the lexer is not as easy to say.

Arne

[toc] | [prev] | [next] | [standalone]

#20877

On Wed, 2 Jan 2013 00:20:12 -0800 (PST), "Aryeh M. Friedman"
<Aryeh.Friedman@gmail.com> wrote, quoted or indirectly quoted someone
who said :

> (\uXXXX)

The only places you encounter such escapes are in Java source and
possibly resource bundles.

Other types of escape you run into are like &eacute;, &#0x0123;
or &#123;
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#20888

On 1/2/2013 2:17 PM, Roedy Green wrote:
> On Wed, 2 Jan 2013 00:20:12 -0800 (PST), "Aryeh M. Friedman"
> <Aryeh.Friedman@gmail.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> (\uXXXX)
>
> The only places you encounter such escapes are in Java source and
> possibly resource bundles.

Well - since he is writing a lexer for Java then ...

Arne

[toc] | [prev] | [next] | [standalone]

#20891

> 
> Well - since he is writing a lexer for Java then ...

A little more on the project... while the over all project *IS* for fun a few components may find there way into more serious work related projects but only to be used on code written by me or others on my team... specifically we may use the lexing/parsing component to make the following tools (the actual code generation/etc. of the compilation is currently purely fun [see note]):

1. Scan for a complete list of classes referenced by a given class (our build system sometimes hiccups on not realizing that when class X calls an instance of class Y and Y has been modified it needs to recompile X {if, and only  if, the signature(s) have changed})

2. Do some minor style enforcement like warning (have not decided if it should reject or just warn) if a class/method does not have something that at least looks like a javadoc header comment (/** ... */ is sufficient for this purpose)

Note:

A long term personal project of mine is to write a OS completely from the ground up in a super set of Java (the only addition I see that is needed is some type of "safe" pointer type)... in this case safe being defined as you can assign a literal address to it but your not allowed to do ptr math on it

[toc] | [prev] | [next] | [standalone]

#20892

On Wednesday, January 2, 2013 8:27:21 PM UTC-5, Aryeh M. Friedman wrote:
> > 
> 
> > Well - since he is writing a lexer for Java then ...
> 
> 
> 
> A little more on the project... while the over all project *IS* for fun a few components may find there way into more serious work related projects but only to be used on code written by me or others on my team... specifically we may use the lexing/parsing component to make the following tools (the actual code generation/etc. of the compilation is currently purely fun [see note]):
> 
> 
> 
> 1. Scan for a complete list of classes referenced by a given class (our build system sometimes hiccups on not realizing that when class X calls an instance of class Y and Y has been modified it needs to recompile X {if, and only  if, the signature(s) have changed})
> 
> 
> 
> 2. Do some minor style enforcement like warning (have not decided if it should reject or just warn) if a class/method does not have something that at least looks like a javadoc header comment (/** ... */ is sufficient for this purpose)
> 
> 
> 
> Note:
> 
> 
> 
> A long term personal project of mine is to write a OS completely from the ground up in a super set of Java (the only addition I see that is needed is some type of "safe" pointer type)... in this case safe being defined as you can assign a literal address to it but your not allowed to do ptr math on it

In case anyone is interested I have some personal notes on the project at http://dt.fnwe.net/a-javacNative/

[toc] | [prev] | [next] | [standalone]

#20895

On Wednesday, January 2, 2013 5:27:21 PM UTC-8, Aryeh M. Friedman wrote:
> > 
> 
> > Well - since he is writing a lexer for Java then ...
> 
> 
> 
> A little more on the project... while the over all project *IS* for fun a few components may find there way into more serious work related projects but only to be used on code written by me or others on my team... specifically we may use the lexing/parsing component to make the following tools (the actual code generation/etc. of the compilation is currently purely fun [see note]):

And your team can't use a real Java compiler because ... ?

> 1. Scan for a complete list of classes referenced by a given class (our build system sometimes hiccups on not realizing that when class X calls an instance of class Y and Y has been modified it needs to recompile X {if, and only  if, the signature(s) have changed})

There are standard build systems that handle this. What do you use?

> 2. Do some minor style enforcement like warning (have not decided if it should reject or just warn) if a class/method does not have something that at least looks like a javadoc header comment (/** ... */ is sufficient for this purpose)

Lint. Findbugs. And more. Why reinvent the wheel?

> Note:
> A long term personal project of mine is to write a OS completely from the ground up in a super set of Java (the only addition I see that is needed is some type of "safe" pointer type)... in this case safe being defined as you can assign a literal address to it but your not allowed to do ptr math on it

Also known as "a JVM"?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20897

On Wednesday, January 2, 2013 8:42:57 PM UTC-5, Lew wrote:
> On Wednesday, January 2, 2013 5:27:21 PM UTC-8, Aryeh M. Friedman wrote:
> 
> > > 
> 
> > 
> 
> > > Well - since he is writing a lexer for Java then ...
> 
> > 
> 
> > 
> 
> > 
> 
> > A little more on the project... while the over all project *IS* for fun a few components may find there way into more serious work related projects but only to be used on code written by me or others on my team... specifically we may use the lexing/parsing component to make the following tools (the actual code generation/etc. of the compilation is currently purely fun [see note]):
> 
> 
> 
> And your team can't use a real Java compiler because ... ?
> 
> 
> 
> > 1. Scan for a complete list of classes referenced by a given class (our build system sometimes hiccups on not realizing that when class X calls an instance of class Y and Y has been modified it needs to recompile X {if, and only  if, the signature(s) have changed})
> 
> 
> 
> There are standard build systems that handle this. What do you use?

Aegis/cook (aegis.sf.net) and the issue is not the build system per se but how most build system deals the split source view aegis provides (which the aegis documentation correctly points out *ALMOST* no build system deals with correctly except for cook)... i.e. every build system makes the assumes that there is a single definition of each compilation unit where aegis makes it so the current version and all previous versions are available (this makes tracking what changes have been made much easier then say cvs/svn/git besides none of them are truly atomic interms of commits {you have to prove your code works before committing it and this is enforced by the VC system).

> 
> 
> 
> > 2. Do some minor style enforcement like warning (have not decided if it should reject or just warn) if a class/method does not have something that at least looks like a javadoc header comment (/** ... */ is sufficient for this purpose)
> 
> 
> 
> Lint. Findbugs. And more. Why reinvent the wheel?

Because there are other style issues that are not enforced (but are propitiatory) that make those unusable

> 
> 
> 
> > Note:
> 
> > A long term personal project of mine is to write a OS completely from the ground up in a super set of Java (the only addition I see that is needed is some type of "safe" pointer type)... in this case safe being defined as you can assign a literal address to it but your not allowed to do ptr math on it
> 
> 
> 
> Also known as "a JVM"?

As far I know the JVM can not be directly booted (as in if I turn on my PC it can not boot into the JVM)... neither for performance reasons does it make sense to run a VM at the bottom layer... an other reason is there is a lot of junk in the JRE (like how do you do garbage collection if you do not have some way of the OS allocating mem to a process in the first place)
> 
> 
> 
> -- 
> 
> Lew

[toc] | [prev] | [next] | [standalone]

#20898

On Wednesday, January 2, 2013 8:55:19 PM UTC-5, Aryeh M. Friedman wrote:
> On Wednesday, January 2, 2013 8:42:57 PM UTC-5, Lew wrote:
> 
> > On Wednesday, January 2, 2013 5:27:21 PM UTC-8, Aryeh M. Friedman wrote:
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Well - since he is writing a lexer for Java then ...
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > A little more on the project... while the over all project *IS* for fun a few components may find there way into more serious work related projects but only to be used on code written by me or others on my team... specifically we may use the lexing/parsing component to make the following tools (the actual code generation/etc. of the compilation is currently purely fun [see note]):
> 
> > 
> 
> > 
> 
> > 
> 
> > And your team can't use a real Java compiler because ... ?

Who said we aren't I only said the lexing/parsing components would be used the team the actual code generation is purely for fun.

> Aegis/cook (aegis.sf.net) and the issue is not the build system per se but how most build system deals the split source view aegis provides (which the aegis documentation correctly points out *ALMOST* no build system deals with correctly except for cook)... i.e. every build system makes the assumes that there is a single definition of each compilation unit where aegis makes it so the current version and all previous versions are available (this makes tracking what changes have been made much easier then say cvs/svn/git besides none of them are truly atomic interms of commits {you have to prove your code works before committing it and this is enforced by the VC system).

Also cook is the only build system (besides make) that I have dealt that does not make extremely hard and often incorrect assumptions about your environment for example ant/maven/etc. are a nightmare for anything besides Java (we often have 2 or 3 langs in one project) and very often the assume your using a IDE (and often a specific one) where we do all our work from the command line by company policy (we have never found a IDE that correctly handles stuff like making completely standalone executable jars and such)

[toc] | [prev] | [next] | [standalone]

#20899

On 1/2/2013 9:02 PM, Aryeh M. Friedman wrote:
> On Wednesday, January 2, 2013 8:55:19 PM UTC-5, Aryeh M. Friedman
>> Aegis/cook (aegis.sf.net) and the issue is not the build system per
>> se but how most build system deals the split source view aegis
>> provides (which the aegis documentation correctly points out
>> *ALMOST* no build system deals with correctly except for cook)...
>> i.e. every build system makes the assumes that there is a single
>> definition of each compilation unit where aegis makes it so the
>> current version and all previous versions are available (this makes
>> tracking what changes have been made much easier then say
>> cvs/svn/git besides none of them are truly atomic interms of
>> commits {you have to prove your code works before committing it and
>> this is enforced by the VC system).
>
> Also cook is the only build system (besides make) that I have dealt
> that does not make extremely hard and often incorrect assumptions
> about your environment for example ant/maven/etc. are a nightmare for
> anything besides Java (we often have 2 or 3 langs in one project)

Ant and maven are designed for Java. They work fine for Java and
Java compatible languages.

They may not work great for completely unrelated languages.

But they can activate other build systems and most other build
systems can activate them.

>                                                                and
> very often the assume your using a IDE (and often a specific one)

ant and maven does not make such assumption.

> where we do all our work from the command line by company policy (we
> have never found a IDE that correctly handles stuff like making
> completely standalone executable jars and such)

All Java IDE's that I know can do that.

So can ant and maven.

Arne

[toc] | [prev] | [next] | [standalone]

#20901

> All Java IDE's that I know can do that.

Let's see we have tried eclipse, netbeans, bluej, dr. java and a few others and every single one failed to produce jars that can be run without after build changes to the manifest and/or needed libs that came with the IDE

> So can ant and maven.

Ant and Maven can agreed

[toc] | [prev] | [next] | [standalone]

#20904

On 1/2/2013 9:16 PM, Aryeh M. Friedman wrote:
>> All Java IDE's that I know can do that.
>
> Let's see we have tried eclipse, netbeans, bluej, dr. java and a few
> others and every single one failed to produce jars that can be run
> without after build changes to the manifest and/or needed libs that
> came with the IDE

It can be done.

Obviously it can also be made not to work.

Maybe you should master a Java IDE before writing an OS in Java.

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#20905

On Wednesday, January 2, 2013 9:20:09 PM UTC-5, Arne Vajhøj wrote:
> On 1/2/2013 9:16 PM, Aryeh M. Friedman wrote:
> 
> >> All Java IDE's that I know can do that.
> 
> >
> 
> > Let's see we have tried eclipse, netbeans, bluej, dr. java and a few
> 
> > others and every single one failed to produce jars that can be run
> 
> > without after build changes to the manifest and/or needed libs that
> 
> > came with the IDE
> 
> 
> 
> It can be done.
> 
> 
> 
> Obviously it can also be made not to work.
> 
> 
> 
> Maybe you should master a Java IDE before writing an OS in Java.

an other requirement not satisfied by any IDE we have found is the ability to lay the source tree out in such a way that it can be compiled without the IDE (a requirement for almost all our projects because none of our clients have IDE's and in almost all cases there are minor changes needed to make the code happy on their site that make testing impossible on the development machine)

[toc] | [prev] | [next] | [standalone]

#20906

On 1/2/2013 9:22 PM, Aryeh M. Friedman wrote:
> an other requirement not satisfied by any IDE we have found is the
> ability to lay the source tree out in such a way that it can be
> compiled without the IDE (a requirement for almost all our projects
> because none of our clients have IDE's and in almost all cases there
> are minor changes needed to make the code happy on their site that
> make testing impossible on the development machine)

The Java IDE's I know put code in a structure that fits
java tools, ant and maven.

Arne

[toc] | [prev] | [next] | [standalone]

#20907

On Wednesday, January 2, 2013 9:26:03 PM UTC-5, Arne Vajhøj wrote:
> On 1/2/2013 9:22 PM, Aryeh M. Friedman wrote:
> 
> > an other requirement not satisfied by any IDE we have found is the
> 
> > ability to lay the source tree out in such a way that it can be
> 
> > compiled without the IDE (a requirement for almost all our projects
> 
> > because none of our clients have IDE's and in almost all cases there
> 
> > are minor changes needed to make the code happy on their site that
> 
> > make testing impossible on the development machine)
> 
> 
> 
> The Java IDE's I know put code in a structure that fits
> 
> java tools, ant and maven.
> 
> 
> 
> Arne

And in almost any non-trivial case this is completely incorrect... even though I love Java as a lang I have a serious issue with some of the attitudes/assumptions made by tools... namely the universe does not revolve around the JVM

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web