Java 8 and Lambdas

[Tom Maynard]

On 04-Apr-14 03:23, Kermit Kiser wrote:

Finally got some time to look at Java 8 and run a few experiments

I forgot to include in my earlier note that (as you might expect) yet another article has popped up on the topic of Java 8 Lambdas, this one a bit more negative: The Dark Side of Lambda Expressions in Java 8.

You'll find it pretty fascinating reading, I'm sure.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

 On 04.04.2014 14:08, Tom Maynard wrote:

On 04-Apr-14 03:23, Kermit Kiser wrote:

a short test...using hard coded Predicate and Consumer classes

Could we see the source for those, too, please? 

Let me be clear: I never felt that NetRexx *needed* lambda expressions -- as you demonstrate with your workaround here. 

Actually, there is no workaround, it is a straightforward implementation that allows NetRexx to be used to take advantage of the new patterns in Java. Kermit supplied the source already, which proofs that NetRexx is so easy that one does overlook the solution sometimes (maybe too human centric? ;) ):

class Pred implements Predicate
    method test(s=Object) returns boolean
        return Rexx(s.toString).pos('k')>0
       
class Eatem implements Consumer
    method accept(s=Object)
        say ">>"s"<<"       

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

On 04-Apr-14 07:41, Rony G. Flatscher (wu-wien) wrote:

 Kermit supplied the source already

Well, that's embarrassing.  I'm going to blame it on a "scroll bar problem" ... but it's purely an example of "Error 60" (the distance in cm between the user's eyes and the screen).

Thanks for pointing that out, Rony.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Not your fault - one of my few dislikes for NetRexx has always been the lack of nested classes (yes, I opened a ticket) which means that by the time you find a filter definition in the code, you have forgotten what it is used for! I sort of understand why Mike felt that private/minor/inner classes should reside at the end of the program source (has to do with error report line numbers, I think) but it sometimes makes code hard to read.

On 4/4/2014 5:52 AM, Tom Maynard wrote:

On 04-Apr-14 07:41, Rony G. Flatscher (wu-wien) wrote:

 Kermit supplied the source already

Well, that's embarrassing.  I'm going to blame it on a "scroll bar problem" ... but it's purely an example of "Error 60" (the distance in cm between the user's eyes and the screen).

Thanks for pointing that out, Rony.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

Not your fault - one of my few dislikes for NetRexx has always been the lack of nested classes (yes, I opened a ticket) which means that by the time you find a filter definition in the code, you have forgotten what it is used for! I sort of understand why Mike felt that private/minor/inner classes should reside at the end of the program source (has to do with error report line numbers, I think) but it sometimes makes code hard to read. 

 

It was nothing to do with 'mechanics'  (errors/line numbers/etc.).   Much more a philosophical intent to try and keep nesting levels as small as possible, along with keeping 'service routines' out of sight and out of mind.   That's a disadvantage if one is using an editor that only allows a single view of a given program source.   I never imagined that such editors would still be in use today <sigh>.

 

Mike  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Mike,

I'd like to understand your vision of how an editor which allows multiple views would work. 

Eclipse and the other IDEs certainly can provide multiple windows, etc. so it might be an interesting project. 

Bill

On 4/4/2014 12:40 PM, Mike Cowlishaw wrote:

 

Not your fault - one of my few dislikes for NetRexx has always been the lack of nested classes (yes, I opened a ticket) which means that by the time you find a filter definition in the code, you have forgotten what it is used for! I sort of understand why Mike felt that private/minor/inner classes should reside at the end of the program source (has to do with error report line numbers, I think) but it sometimes makes code hard to read. 

 

It was nothing to do with 'mechanics'  (errors/line numbers/etc.).   Much more a philosophical intent to try and keep nesting levels as small as possible, along with keeping 'service routines' out of sight and out of mind.   That's a disadvantage if one is using an editor that only allows a single view of a given program source.   I never imagined that such editors would still be in use today <sigh>.

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

There is a possible misunderstanding here that I would like to address. NetRexxC reads all imported Java class files before beginning a compile and translates the Java bytecode into internal data structures that will be needed during the compile. NetRexx has to understand Java bytecode in order to work. That is why René's patch for issue #106 is needed to make NetRexx work with Java 8: three new JVM op codes were added to Java 7 but not really used much until Java 8 and NetRexx needs to handle those op codes.

In addition to the above processing, after NetRexxC calls a Java compiler to produce a bytecode class module, it then reads the Java compiler output class code, analyzes and modifies it and rewrites it after deleting the class file produced by the Java compiler. This is done to trick the JVM into seeing the NetRexx source program name rather than the name of the Java code file that the Java compiler actually processed.

I just wanted to clarify that NetRexx is by no means independent of Java bytecode. In theory, NetRexx calling javac allows it to use any optimizations that the Java compiler people develop. In reality Java optimization occurs at runtime in the JIT process of the JVM. And since NetRexx now optionally uses the "ecj" Java compiler from Eclipse, it can create quite different bytecode from javac at times.

-- Kermit

On 3/26/2014 5:34 PM, George Hovey wrote:

Re "Since NetRexx translates to Java source, and javac does the heavy lifting on the bytecode end"

I take this to be further confirmation of the wisdom of that approach.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

I'd like to understand your vision of how an editor which allows multiple views would work.  
 

Many of the editors on VM and OS/2 (1980s) worked that way.  One could open the same file with several windows, scroll up and down in each.  Typically where one was entering new program text was the 'main' window, other windows could be opened to view/edit subroutines in the same program (for example).  If windows overlapped the same data then changes in one window appeared in the other windows too (on VM, on pressing Enter).

 

Some editors 'cheated' by only allowing changes in one window; any other views of the same file were read-only. 

 

The common idea was allowing the programmer to see multiple views into the same file.

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

There is a possible misunderstanding here that I would like to address. NetRexxC reads all imported Java class files before beginning a compile and translates the Java bytecode into internal data structures that will be needed during the compile. NetRexx has to understand Java bytecode in order to work. That is why René's patch for issue #106 is needed to make NetRexx work with Java 8: three new JVM op codes were added to Java 7 but not really used much until Java 8 and NetRexx needs to handle those op codes.

In addition to the above processing, after NetRexxC calls a Java compiler to produce a bytecode class module, it then reads the Java compiler output class code, analyzes and modifies it and rewrites it after deleting the class file produced by the Java compiler. This is done to trick the JVM into seeing the NetRexx source program name rather than the name of the Java code file that the Java compiler actually processed.

I just wanted to clarify that NetRexx is by no means independent of Java bytecode. In theory, NetRexx calling javac allows it to use any optimizations that the Java compiler people develop. In reality Java optimization occurs at runtime in the JIT process of the JVM. And since NetRexx now optionally uses the "ecj" Java compiler from Eclipse, it can create quite different bytecode from javac at times.
 

Possibly there have been changes, but I don't recall NetRexxC ever looking at bytecode.  .class files, yes, to get signatures, etc., but I think it was not bytecode-aware?

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

jEdit does exactly this.  You may create multiple windows and subdivide each of these horizontally and/or vertically into any number of 'panes'.  You are free to open multiple views on any or all of your files.

On Sat, Apr 5, 2014 at 10:31 AM, Mike Cowlishaw <[hidden email]> wrote:

I'd like to understand your vision of how an editor which allows multiple views would work.  
 

Many of the editors on VM and OS/2 (1980s) worked that way.  One could open the same file with several windows, scroll up and down in each.  Typically where one was entering new program text was the 'main' window, other windows could be opened to view/edit subroutines in the same program (for example).  If windows overlapped the same data then changes in one window appeared in the other windows too (on VM, on pressing Enter).

 

Some editors 'cheated' by only allowing changes in one window; any other views of the same file were read-only. 

 

The common idea was allowing the programmer to see multiple views into the same file.

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
"One can live magnificently in this world if one knows how to work and how to love."  --  Leo Tolstoy

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

On 05-Apr-14 10:45, George Hovey wrote:

jEdit does exactly this.  You may create multiple windows and subdivide each of these horizontally and/or vertically into any number of 'panes'.

I can't think of any "modern" editor that doesn't support either panes/frames or tabs, with horizontal/vertical splitting, etc.  Perhaps Notepad, but I confess I've never opened the copy on my system here.  Failing that built-in support, you could also fall back to multiple instances of the editor, all open to the same file, but at different locations.

Personally, I use Vim which is really an ancient editor -- but kept up-to-date and bursting with features by a dedicated developer, and it incorporates all of these features (and more).  [Before the flame throwers emerge: I also have Emacs installed, and I use that, too.]

Even TSE, a PC editor I used when I was still hacking IBM mainframe assembler by day and which persists to this day, supports multi-file edits (or multiple views into the same file).  TSE has evolved from Qedit, beginning in 1985 ... truly ancient times in PC-speak.  (I still have a licensed copy, but find it too quirky and "old fashioned" for serious use today.  It's still blazing fast and incredibly tiny, though.)

Nearly all of MFC's visionary ideals have been reached by now ... at least those I know about.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

I can't think of any "modern" editor that doesn't support either panes/frames or tabs, with horizontal/vertical splitting, etc.  Perhaps Notepad, but I confess I've never opened the copy on my system here.  Failing that built-in support, you could also fall back to multiple instances of the editor, all open to the same file, but at different locations. 

 

This is a really bad idea in most cases .. make different changes in different windows and a save in one wipes out the changes in the others. 

Personally, I use Vim which is really an ancient editor -- but kept up-to-date and bursting with features by a dedicated developer, and it incorporates all of these features (and more).  [Before the flame throwers emerge: I also have Emacs installed, and I use that, too.]

Even TSE, a PC editor I used when I was still hacking IBM mainframe assembler by day and which persists to this day, supports multi-file edits (or multiple views into the same file).  TSE has evolved from Qedit, beginning in 1985 ... truly ancient times in PC-speak.  (I still have a licensed copy, but find it too quirky and "old fashioned" for serious use today.  It's still blazing fast and incredibly tiny, though.)

Nearly all of MFC's visionary ideals have been reached by now ... at least those I know about. 

 

Nothing 'visionary' about them -- I used editors that worked that way more than thirty years ago.  Today's crop of editors do not, in general, seem to have the concept.  

 

But let's not drift into editor religion; this forum is about NetRexx...

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

LOL! You are precisely correct of course.

On April 5, 2014 7:34:20 AM PDT, Mike Cowlishaw <[hidden email]> wrote:

 

There is a possible misunderstanding here that I would like to address. NetRexxC reads all imported Java class files before beginning a compile and translates the Java bytecode into internal data structures that will be needed during the compile. NetRexx has to understand Java bytecode in order to work. That is why René's patch for issue #106 is needed to make NetRexx work with Java 8: three new JVM op codes were added to Java 7 but not really used much until Java 8 and NetRexx needs to handle those op codes.

In addition to the above processing, after NetRexxC calls a Java compiler to produce a bytecode class module, it then reads the Java compiler output class code, analyzes and modifies it and rewrites it after deleting the class file produced by the Java compiler. This is done to trick the JVM into seeing the NetRexx source program name rather than the name of the Java code file that the Java compiler actually processed.

I just wanted to clarify that NetRexx is by no means independent of Java bytecode. In theory, NetRexx calling javac allows it to use any optimizations that the Java compiler people develop. In reality Java optimization occurs at runtime in the JIT process of the JVM. And since NetRexx now optionally uses the "ecj" Java compiler from Eclipse, it can create quite different bytecode from javac at times.
 

Possibly there have been changes, but I don't recall NetRexxC ever looking at bytecode.  .class files, yes, to get signatures, etc., but I think it was not bytecode-aware?

 

Mike

Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
Sent from my Android tablet with K-9 Mail.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

On 05-Apr-14 13:40, Mike Cowlishaw wrote:

Nothing 'visionary' about them -- I used editors that worked that way more than thirty years ago

Well, I wasn’t limiting myself strictly to editors … but Computer Science in the large (as you yourself mention in a subsequent note on the RexxLA list).

Look at the current crop of “human-centric” languages, for instance (Nimrod, Xtend, Xtext, Simple, …), and the increasing spread of decimal arithmetic, and many, many more … and I still am only aware of a fraction of them.

But let's not drift into editor religion; this forum is about NetRexx...

Just so. I’ll leave my praise for MFC at the altar instead.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/