Safety Critical Java Technology standard

Nothing?

On Jan 20, 3:08 pm, "Russ P." wrote:
> I recently came across a draft document called Safety Critical Java
> Technology (JSR-000302):
>
> http://jcp.org/aboutJava/communityprocess/edr/jsr302/index.html
>
> I am trying to understand the significance of the standard specified
> in this document, and I have a few questions about it.
>
> Is anyone doing or planning to do any safety-critical programming in
> Java? If so, are you aware of this standard? Are you using it or
> planning to use it? Are you aware of anyone else who is using it?
>
> If the decision were yours to make, would you consider developing
> safety-critical software in Java (at the level of, say, DO-178B Level
> A or B) without basing it on this standard? In other words, would you
> consider this standard optional or essential?
>
> Also, how does Scala fit in, or does it? Can Scala code conform to
> this standard by calling the associated Java libraries? What are the
> chances of a standard like this being produced for Scala?
>
> Comments are welcome. Thanks.
>
> --Russ P.

Hi Russ,

I'm not directly engaged in "safety-critical programming". On reading
up, my first feeling was that this stuff may just be a kind of
marketing campaign for certain libraries of certain vendors. What is
your impression?

I'd suggest to ask Typesafe directly, anyway.

Peter

http://java.sun.com/j2se/1.4.2/j2re-1_4_2_02-license.html

Well, Java isn't considered safe for Nukes...

3) RESTRICTIONS. Software is confidential and copyrighted. Title to
Software and all associated intellectual property rights is retained
by Sun and/or its licensors. Unless enforcement is prohibited by
applicable law, you may not modify, decompile, or reverse engineer
Software. You acknowledge that Licensed Software is not designed or
intended for use in the design, construction, operation or maintenance
of any nuclear facility.... etc etc

And, it doesn't come with any Warranty or implied fitness for any
purpose...

5) DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL
EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE
EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

Perhaps you should be looking at ADA or some industrial Haskell
implementation.

uh, i think the point is that they are trying to fix those old, old
issues, at least for some flavour of java/jvm. no?

On Wed, Jan 25, 2012 at 11:07 AM, bryan hunt
wrote:
> http://java.sun.com/j2se/1.4.2/j2re-1_4_2_02-license.html
>
> Well, Java isn't considered safe for Nukes...
>
> 3) RESTRICTIONS. Software is confidential and copyrighted. Title to
> Software and all associated intellectual property rights is retained
> by Sun and/or its licensors. Unless enforcement is prohibited by
> applicable law, you may not modify, decompile, or reverse engineer
> Software.  You acknowledge that Licensed Software is not designed or
> intended for use in the design, construction, operation or maintenance
> of any nuclear facility.... etc etc
>
> And, it doesn't come with any Warranty or implied fitness for any
> purpose...
>
> 5) DISCLAIMER OF WARRANTY.  UNLESS SPECIFIED IN THIS AGREEMENT, ALL
> EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
> INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
> PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE
> EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
>
> Perhaps you should be looking at ADA or some industrial Haskell
> implementation.

On Jan 25, 12:32 am, Sonnenschein wrote:
> Hi Russ,
>
> I'm not directly engaged in "safety-critical programming". On reading
> up, my first feeling was that this stuff may just be a kind of
> marketing campaign for certain libraries of certain vendors. What is
> your impression?

I doubt that. This standard was put together by a committee from
several different companies. It's also part of the Java Community
Process (JCP), which I assume is a legitimate organization. (If it
isn't, please let me know.)

--Russ P.

On Jan 25, 11:07 am, bryan hunt wrote:
> http://java.sun.com/j2se/1.4.2/j2re-1_4_2_02-license.html
>
> Well, Java isn't considered safe for Nukes...
>
> 3) RESTRICTIONS. Software is confidential and copyrighted. Title to
> Software and all associated intellectual property rights is retained
> by Sun and/or its licensors. Unless enforcement is prohibited by
> applicable law, you may not modify, decompile, or reverse engineer
> Software.  You acknowledge that Licensed Software is not designed or
> intended for use in the design, construction, operation or maintenance
> of any nuclear facility.... etc etc
>
> And, it doesn't come with any Warranty or implied fitness for any
> purpose...
>
> 5) DISCLAIMER OF WARRANTY.  UNLESS SPECIFIED IN THIS AGREEMENT, ALL
> EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
> INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
> PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE
> EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

That's all standard legal disclaimer. I assume it applies only to Java
itself, not any specific Java application or library.

> Perhaps you should be looking at ADA or some industrial Haskell
> implementation.

I looked into Ada a few years ago. Its a solid language, but it really
seems to be all but forgotten, perhaps due to its awkward, "clunky"
syntax. It still has a significant installed base, but as far as I
know it is rarely used for new projects other than perhaps military
weapon systems and high-end avionic systems. As far as I know, it is
still the standard language for flight-critical software.

--Russ P.

Russ - 
I think the important point here is that the JCP is home to a gazillion extremely-domain-specific committees who talk about Java implementations for requirements which 99.9999% of developers do not have.
It's not reasonable to expect EPFL to have an opinion on any JSR in particular; most are about libraries (or APIs) and a few are language-level.
If I was EPFL, I think my position would be "we are not stopping you from using Java where it meets your requirements"
Chris

> Date: Wed, 25 Jan 2012 17:27:49 -0800
> Subject: [scala-user] Re: Safety Critical Java Technology standard
> From: russ.paielli@gmail.com
> To: scala-user@googlegroups.com
>
> On Jan 25, 12:32 am, Sonnenschein <peter.em...@arcor.de> wrote:
> > Hi Russ,
> >
> > I'm not directly engaged in "safety-critical programming". On reading
> > up, my first feeling was that this stuff may just be a kind of
> > marketing campaign for certain libraries of certain vendors. What is
> > your impression?
>
> I doubt that. This standard was put together by a committee from
> several different companies. It's also part of the Java Community
> Process (JCP), which I assume is a legitimate organization. (If it
> isn't, please let me know.)
>
> --Russ P.

On Jan 26, 12:25 am, Chris Marshall wrote:
> Russ -
> I think the important point here is that the JCP is home to a gazillion extremely-domain-specific committees who talk about Java implementations for requirements which 99.9999% of developers do not have.

That's true, but the JSR for Safety Critical Java Technology
Specification is not quite in the same category as some arcane JSR.
Granted, few Java programmers will ever work on safety-critical
software. But what is "safety-critical" software anyway? From the
developer's perspective, it is simply real-time software that *must*
function correctly, with no major bugs and very few, if any, minor
bugs.

But the absence of bugs is the ideal for any program. The issue is not
whether you want bugs or not, but what technologies and methods should
be used and how much time and effort should go into eliminating them.
That is why I would think that any language designer who takes
verifiable correctness seriously should have an opinion about the
requirements for safety-critical software.

> It's not reasonable to expect EPFL to have an opinion on any JSR in particular; most are about libraries (or APIs) and a few are language-level.
> If I was EPFL, I think my position would be "we are not stopping you from using Java where it meets your requirements"
> Chris

I have suggested in the past that someone might want to consider a
"safe" subset of Scala for safety-critical applications. I really
don't know if that makes sense for Scala, but there are safe subsets
of Ada, so it is not a new idea.

In any case, what surprised me about the Safety Critical Java
Technology Specification is that it actually requires the use of
specific libraries that, unless I am mistaken, are not part of the
Java Standard Library. I am trying to understand whether that makes
sense and what the implications are for Scala. If someone claimed that
the Scala Standard Library is inadequate for safety-critical use and
always will be, I wonder if anyone at EPFL or Typesafe would object.

--Russ P.

Slightly related to your post: there is one project called joe-e[1] that gives some security guarantees for runnable code, which might interest you.

[1] http://code.google.com/p/joe-e/

On 21 January 2012 00:08, Russ P. <russ.paielli@gmail.com> wrote:

I recently came across a draft document called Safety Critical Java
Technology (JSR-000302):

http://jcp.org/aboutJava/communityprocess/edr/jsr302/index.html

I am trying to understand the significance of the standard specified
in this document, and I have a few questions about it.

Is anyone doing or planning to do any safety-critical programming in
Java? If so, are you aware of this standard? Are you using it or
planning to use it? Are you aware of anyone else who is using it?

If the decision were yours to make, would you consider developing
safety-critical software in Java (at the level of, say, DO-178B Level
A or B) without basing it on this standard? In other words, would you
consider this standard optional or essential?

Also, how does Scala fit in, or does it? Can Scala code conform to
this standard by calling the associated Java libraries? What are the
chances of a standard like this being produced for Scala?

Comments are welcome. Thanks.

--Russ P.

Hi,
I am relatively new to scala, and I am not understanding few concepts related to function arguments. Please take a look at the code below. The behavior is the same for all three function call- Calls f1, then f2 then pm. I am not understanding why I cant use function _ in the code (I have put a comment). What is the difference between f: => String and f:() => String? When to use the specific syntax? 
object Tester {
def main(args:Array[String]){  def pm = {    println("In PM")    "PM"  }      val a = A(1, pm _)  a.f1() //Call 1            //Call 2  f1(1){  //Cant use pm _ here, why?    pm  }
  //Call 3  f1Dash(1, pm) //Cant use pm _ here, why? }
  def f1Dash(i:Int, f: => String) = {    println("In F1Dash, calling F2") f2(f)  }    def f1(i:Int)( f: => String) = {    println("In F1, calling F2") f2(f)  }    def f2(f: => String){    println("In F2, calling f")    f  }}
case class A(i:Int, f:() => String){  def f1() = {  println("In F1, calling F2")  f2(f())  }    def f2(f: => String){    println("In F2, calling f")    f  }}
Thanks,Shreyas Purohit

Please ignore... Sent by mistake, very new to using this..
From: shreyas.purohit@hotmail.com
To: scala-user@googlegroups.com
Subject: Function arguments confusion
Date: Sat, 28 Jan 2012 03:59:03 +0530

.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Tahoma;} Hi,
I am relatively new to scala, and I am not understanding few concepts related to function arguments. Please take a look at the code below. The behavior is the same for all three function call- Calls f1, then f2 then pm. I am not understanding why I cant use function _ in the code (I have put a comment). What is the difference between f: => String and f:() => String? When to use the specific syntax? 
object Tester {
def main(args:Array[String]){  def pm = {    println("In PM")    "PM"  }      val a = A(1, pm _)  a.f1() //Call 1            //Call 2  f1(1){  //Cant use pm _ here, why?    pm  }
  //Call 3  f1Dash(1, pm) //Cant use pm _ here, why? }
  def f1Dash(i:Int, f: => String) = {    println("In F1Dash, calling F2") f2(f)  }    def f1(i:Int)( f: => String) = {    println("In F1, calling F2") f2(f)  }    def f2(f: => String){    println("In F2, calling f")    f  }}
case class A(i:Int, f:() => String){  def f1() = {  println("In F1, calling F2")  f2(f())  }    def f2(f: => String){    println("In F2, calling f")    f  }}
Thanks,Shreyas Purohit

On Fri, Jan 27, 2012 at 20:29, shreyas purohit
wrote:
> Hi,
>
> I am relatively new to scala, and I am not understanding few concepts
> related to function arguments. Please take a look at the code below. The
> behavior is the same for all three function call- Calls f1, then f2 then pm.
> I am not understanding why I cant use function _ in the code (I have put a
> comment). What is the difference between f: => String and f:() => String?
> When to use the specific syntax?

"function _" turns a named function (a method) into an anonymous
function (an object).

The type () => String is a function with 0 parameters that returns String.

The declaration "=> String" means a String parameter passed by-name.

>
> object Tester {
>
> def main(args:Array[String]){
>  def pm = {
>    println("In PM")
>    "PM"
>  }
>
>  val a = A(1, pm _)
>  a.f1() //Call 1
>
>           //Call 2
>  f1(1){  //Cant use pm _ here, why?

f1 expects a String parameter, which will be passed by name, but "pm
_" is a function. They are, therefore, incompatible types.

>    pm
>  }
>
>   //Call 3
>  f1Dash(1, pm) //Cant use pm _ here, why?
> }
>
>   def f1Dash(i:Int, f: => String) = {
>     println("In F1Dash, calling F2")
> f2(f)
>   }
>
>   def f1(i:Int)( f: => String) = {
>     println("In F1, calling F2")
> f2(f)
>   }
>
>   def f2(f: => String){
>     println("In F2, calling f")
>     f
>   }
> }
>
> case class A(i:Int, f:() => String){
>   def f1() = {
>  println("In F1, calling F2")
>  f2(f())
>   }
>
>   def f2(f: => String){
>     println("In F2, calling f")
>     f
>   }
> }
>
> Thanks,
> Shreyas Purohit
>